It allocates a msgb and sends into the IPmux and waits for a response.
This is to allocate the ire. It is not strange, just a streams difference.
I have also seen this on hardware offload, when something has to get a
resource somewhere else and puts it on a waitq in linux.
This makes it work.
On 10/20/08, Yang Tse <yangsita_at_gmail.com> wrote:
> 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]=-
>
-- Sent from Gmail for mobile | mobile.google.comReceived on 2008-10-21