On 1/16/06, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Mon, 16 Jan 2006, Allen Chan wrote:
> 1 - You left some printf() calls in there that I trust you used for debugging
> but they can't be in production code. I suggest you turn them into infof()
> calls instead.

Okay, got it.
>
> 2 - CURLINFO_LOCAL_PORT. As Karl M pointed out, what's the point of having
> libcurl do getsockname() on the socket when your app simply can first
> extract the socket and then do getsockname() on it on its own? Are there
> really situations when you want to extract the local port only without
> getting the socket/connection ?

Getting the port can really be simply isn't it. But I thought I was
trying to make it easier on the programmer (someone may not know how
to do it?) and atleast maybe round out the features.

>
> 3 - CURLINFO_SOCKET suffers from the same flaw(s) that I already mentioned to
> Vadim Lebedev when he posted his patch: the code assumes that the
> connection with the latest time stamp is the most recently used. That is
> not true if the most recently used one in fact was closed, while the
> second to last one was not. It needs a somewhat more robust handling and I
> already suggested that it could be made by having the SessionHandle struct
> keep info about the most recently used connection or similar.

Ah yes, now I understand. I can make those changes. Do you think that
we can store the socket handle on connection? I'm hoping its not on
access since there would be alot of entry points. Meaning, the last
connected socket whether succesful or not.
Received on 2006-01-16