when send() function returns?

Hi,

When you call send(), what actions will be taken and when it will return? I
would like to know underlying mechanisms that will be taken care of when an
application invokes send().

Any help will be highly appreciated.


Sean.

Sean wrote:

> Hi,
>
> When you call send(), what actions will be taken and when it will return? I
> would like to know underlying mechanisms that will be taken care of when an
> application invokes send().

The short answer is it will return after your buffer is copied to an internal
buffer. The long answer will depend on WHY you want to know this information,
because a little understanding of the internal workings of the TCP/IP stack have
gotten many socket programmers into trouble.

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

"Phil Frisbie, Jr." <(E-Mail Removed)> wrote in message
news:449822ce$0$65441$(E-Mail Removed)...
> Sean wrote:
>
>> Hi,
>>
>> When you call send(), what actions will be taken and when it will return?
>> I would like to know underlying mechanisms that will be taken care of
>> when an application invokes send().
>
> The short answer is it will return after your buffer is copied to an
> internal buffer. The long answer will depend on WHY you want to know this
> information, because a little understanding of the internal workings of
> the TCP/IP stack have gotten many socket programmers into trouble.

Thanks for the response. I guess send() returns after copying the data into
the socket send buffer. If the send buffer does not have enough room for
the data, send() will be blocked. Thus, if I keep calling send() fast
enough, then the buffer will be filled up and the send() will not return
until a pakcet is drained from the buffer. Based on this return delay of
send(), I am trying to infer actual sending rate of the network interface
card. This is the reason that I am interested in the internal workings of
send(). I would appreciate if someone shares the information about the
internal works of send(). By the way, I use UDP sockets for this purpose.

Thanks,
Sean.

Sean wrote:

> Thanks for the response. I guess send() returns after copying the data into
> the socket send buffer. If the send buffer does not have enough room for
> the data, send() will be blocked. Thus, if I keep calling send() fast
> enough, then the buffer will be filled up and the send() will not return
> until a pakcet is drained from the buffer. Based on this return delay of
> send(), I am trying to infer actual sending rate of the network interface
> card. This is the reason that I am interested in the internal workings of
> send(). I would appreciate if someone shares the information about the
> internal works of send(). By the way, I use UDP sockets for this purpose.

You were doing well until you said you were using UDP. UDP is not a reliable
protocol, and if you fill up the send buffer UDP datagrams can/will be dropped
to make room, and send() will likely never block.

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

"Phil Frisbie, Jr." <(E-Mail Removed)> wrote in message
news:449970e2$0$96980$(E-Mail Removed)...
> Sean wrote:
>
>> Thanks for the response. I guess send() returns after copying the data
>> into the socket send buffer. If the send buffer does not have enough
>> room for the data, send() will be blocked. Thus, if I keep calling send()
>> fast enough, then the buffer will be filled up and the send() will not
>> return until a pakcet is drained from the buffer. Based on this return
>> delay of send(), I am trying to infer actual sending rate of the network
>> interface card. This is the reason that I am interested in the internal
>> workings of send(). I would appreciate if someone shares the information
>> about the internal works of send(). By the way, I use UDP sockets for
>> this purpose.
>
> You were doing well until you said you were using UDP. UDP is not a
> reliable protocol, and if you fill up the send buffer UDP datagrams
> can/will be dropped to make room, and send() will likely never block.

You mean that sender host's kernel will drop UDP packets even before sending
them out through NIC ? I thought that the sender will never drop packets and
it would wait if room is not available in the buffer. Then, using TCP
sockets will work? I am still interested in internal works (from send() call
to actual packet sending action through NIC).

Sean.

Sean <(E-Mail Removed)> wrote:
> You mean that sender host's kernel will drop UDP packets even before
> sending them out through NIC ? I thought that the sender will never
> drop packets and it would wait if room is not available in the
> buffer. Then, using TCP sockets will work? I am still interested in
> internal works (from send() call to actual packet sending action
> through NIC).

The driver's transmit queue can fill, at which point, the driver will
start tossing subsequent sends. Depending on the stack, you may or
may not get an error return from the send() call when that happens.
Some stacks may have "intra-stack" flow control to back-pressure the
application, but you cannot rely on that. Heck, on some stacks, the
UDP datagram is never "really" queued to the SO_SNDBUF to begin with.

rick jones
http://www.netperf.org/
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

I am still not clear what's going on between send() call and actual sending.
Is there any way to achieve that I want as I described in previous message?

Sean.

"Rick Jones" <(E-Mail Removed)> wrote in message
news:mHfmg.2136$(E-Mail Removed)...
> Sean <(E-Mail Removed)> wrote:
>> You mean that sender host's kernel will drop UDP packets even before
>> sending them out through NIC ? I thought that the sender will never
>> drop packets and it would wait if room is not available in the
>> buffer. Then, using TCP sockets will work? I am still interested in
>> internal works (from send() call to actual packet sending action
>> through NIC).
>
> The driver's transmit queue can fill, at which point, the driver will
> start tossing subsequent sends. Depending on the stack, you may or
> may not get an error return from the send() call when that happens.
> Some stacks may have "intra-stack" flow control to back-pressure the
> application, but you cannot rely on that. Heck, on some stacks, the
> UDP datagram is never "really" queued to the SO_SNDBUF to begin with.
>
> rick jones
> http://www.netperf.org/
> --
> The glass is neither half-empty nor half-full. The glass has a leak.
> The real question is "Can it be patched?"
> these opinions are mine, all mine; HP might not want them anyway...
> feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Sean wrote:
> I am still not clear what's going on between send() call and actual sending.
> Is there any way to achieve that I want as I described in previous message?

Not using Berkeley Sockets while sending. You CAN get a fairly good estimate if
you are receiving a flood of UDP datagrams, but if you need to only depend on
your client computer you will need to delve down lower into the Linux kernel,
down to the NIC driver.

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Sean <(E-Mail Removed)> wrote:
> I am still not clear what's going on between send() call and actual
> sending. Is there any way to achieve that I want as I described in
> previous message?

Being able to just call send() on a UDP socket and "know" that the
datagram was sent? No. At least not with just the one system.

Based on my experiences with netperf, Linux does seem to have
"intra-stack" flow control (try a netperf UDP_STREAM test), but even
that does not _REALLY_ mean that every send() call you make becomes a
packet on the wire.

To _REALLY_ know, without getting hip-deep in the kernel, you have to
know that it was received by another system. That is what the netperf
UDP_STREAM test does. Of course, now you are concerned not only with
did the packet get out the host OK, but did it get up the other host
to the receiving app OK.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...