Edward Russell wrote: > I was seeing this with the default -t u1 flag so doesn't that mean > everything is UDP? Therefore no TCP keep-alive, probes, etc.? With UDP, > the sender has no way of knowing if the receiver is full (and doesn't > care), it just keeps sending. That mean the only way you could get > EAGAIN is if the send buffer was full of its own accord. That is the > application is stuffing packets in faster than the OS can send them. > Absolutely nothing to do with the reciever. > > True?
Seems to be - although I'd make that "faster than the OS/NIC can send them." Depending on the networking stack, you may never see an error (at least one due to overflow) on a send() against a UDP socket. Even when/if the send() call resulted in the UDP datagram being dropped somewhere down the stack. Linux does have _intra-stack_ flow control for UDP, but I've only experienced it with netperf UDP_STREAM, which uses a blocking socket. rick ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
