Subject: Re: [PATCH] UDP non-blocking connect EINPROGRESS

Re: [PATCH] UDP non-blocking connect EINPROGRESS

From: Yang Tse <yangsita_at_gmail.com>
Date: Tue, 21 Oct 2008 02:36:17 +0200

2008/10/20, Charles Hardin <ckhardin_at_gmail.com>:

> Using a streams stack called Mentat.
>
> On 10/20/08, Yang Tse <yangsita_at_gmail.com> wrote:
> > 2008/10/20, Charles Hardin wrote:
> >
> >> On some networking stacks, a UDP connect can also return EINPROGRESS
> >> or EWOULDBLOCK.
> >
> > Out of curiosity, which system's connectionless UDP connect() returns
> > the above errors?
> >
> > --
> > -=[Yang]=-
> >
>
> --
> Sent from Gmail for mobile | mobile.google.com
>

Well, Mentat licensed their TCP/IP stack to a quite big number of
companies, so the question would still stand as to know which system
is the one which with the peculiar/flawed TCP/IP implementation.

A connect() call using a UDP socket will not block unless the TCP/IP
stack design is strangely implemented. It has very little work to do,
keep an internal copy of the destination/peer address, and no network
activity at all.

In any case, if you wish to allow c-ares to work with TCP/IP stacks in
which a connect() call using an UDP socket might return EWOULDBLOCK,
you'll really have to handle that situation in the code.

That means thinking about what to do with the SOCK_STATE_CALLBACK that
now is called only once that the connect call succeeds in
open_udp_socket().

And the worst part awaits in ares__send_query() once you return to it
with an EWOULDBLOCK'ed response from an UDP connect().

Look at it if you please.

If UDP connect can return EWOULDBLOCK, how do you know that the
connect has completed? Remember that this protocol is connectionless.

Really, what system has all this funny stuff?

-- 
-=[Yang]=-
Received on 2008-10-21