Does non-blocking socket use a queue ? How to know if it's full ?
in [Unix Programming]
|
Prev: Where does gdb find source code to display and step through?
Next: Online SUS access (was: directories III)
From: Greg2fs on 1 Mar 2010 05:43 Hi, I use non blocking socket in my UDP client/server program and I ask myself what will happen if I send more data than my connection can handle, I suppose a queue is used internaly, but is it possible to know if it's full and clear it ? Thanks
From: David Schwartz on 1 Mar 2010 06:10 On Mar 1, 2:43 am, Greg2fs <greg...(a)gmail.com> wrote: > Hi, I use non blocking socket in my UDP client/server program and I > ask myself what will happen if I send more data than my connection can > handle, I suppose a queue is used internaly, but is it possible to > know if it's full and clear it ? If you send more data than the connection can handle, some of the datagrams will be dropped. There is no way to know if the queue is full because the queue is not just in one place. For example: A <-> router <-> B If machine A sends UDP datagrams to machine B, there may be a queue in the network card on machine A, a queue on the router between them, and a receive queue on machine B. Any of these queues can be full. There is no way for the queue on the router or on machine B to report its state to you. The best way is to design a protocol layered on top of UDP to detect if a queue is full (by the packet loss) and backoff. If you don't want to take this responsibility, use TCP which handles backoff, retry, and transmit pacing for you. DS
From: Ersek, Laszlo on 1 Mar 2010 09:16 In article <2250226a-06ed-40b5-9f93-348c5aacda81(a)t17g2000prg.googlegroups.com>, David Schwartz <davids(a)webmaster.com> writes: > On Mar 1, 2:43=A0am, Greg2fs <greg...(a)gmail.com> wrote: > >> Hi, I use non blocking socket in my UDP client/server program and I >> ask myself what will happen if I send more data than my connection can >> handle, I suppose a queue is used internaly, but is it possible to >> know if it's full and clear it ? > > If you send more data than the connection can handle, some of the > datagrams will be dropped. There is no way to know if the queue is > full because the queue is not just in one place. > > For example: > > A <-> router <-> B > > If machine A sends UDP datagrams to machine B, there may be a queue in > the network card on machine A, a queue on the router between them, and > a receive queue on machine B. Any of these queues can be full. There > is no way for the queue on the router or on machine B to report its > state to you. > > The best way is to design a protocol layered on top of UDP to detect > if a queue is full (by the packet loss) and backoff. If you don't want > to take this responsibility, use TCP which handles backoff, retry, and > transmit pacing for you. (I don't debate this, just try to add my two cents.) AFAICT, this direct packet loss => congestion (so back off) implication works well under most circumstances and it should indeed be one rule that TCP is based on. However, this inference (ie. packet loss or delay can mean *only* congestion and nothing else) starts to become less unquestionable as we move away from wired networks or towards high-latency links. For example, WiFi links are notoriously bad for TCP, because packet loss is very common. However, the adequate response in this case is not backing off immediately, but pushing forward for a little while, because packet loss is oftentimes not a sign of congestion, ie. full queues. Another example is inter-Atlantic links, which offer huge bandwidth but also come with relatively high latencies. A number of TCP extensions were developed for such situations. This is an active research area in HPC. Some random links from my mailbox: http://udt.sourceforge.net/ ----v---- UDP-based Data Transfer UDT: Breaking the Data Transfer Bottleneck [...] * Supercomputing 2009 Bandwidth Challenge Winner * Supercomputing 2008 Bandwidth Challenge Winner * Supercomputing 2006 Bandwidth Challenge Winner ----^---- http://vfer.sourceforge.net/cgi-bin/index.cgi?page=home ----v---- VFER uses advanced TCP-friendly congestion control that, by taking delay into account, quickly recovers from non-congestive packet loss. ----^---- http://e2epi.internet2.edu/transport/ ----v---- Internet2 Bulk Transport Working Group [...] The Transport working group will address the need of the community for a bulk transport tool that is easy to use on today's advanced networks, is portable across a wide range of platforms, has high performance, can tolerate minor non-congestive packet loss, applicable to both static file transfer and interactive applications, and is TCP-friendly. ----^---- And finally for the OP: if you wish to look at source code that is short, does similar stuff (albeit obviously naively when compared to the projects above), you may want to check out http://freshmeat.net/projects/udp_copy2 which links to my site, or "udpconn2.c" (which doesn't even deserve a freshmeat entry), also on my site. Cheers, lacos http://lacos.hu
From: Ersek, Laszlo on 1 Mar 2010 09:21 In article <26611e7e-016b-480f-908e-dae1aeab2963(a)g28g2000yqh.googlegroups.com>, Greg2fs <greg2fs(a)gmail.com> writes: > Hi, I use non blocking socket in my UDP client/server program and I > ask myself what will happen if I send more data than my connection can > handle, I suppose a queue is used internaly, but is it possible to > know if it's full and clear it ? Sorry for replying twice. Searching for "reliable UDP" on freshmeat: http://freshmeat.net/search?q=reliable+UDP&submit=Search also returns quite a few interesting projects. Cheers, lacos
From: Greg2fs on 2 Mar 2010 12:09
OK, thanks, I don't want to use a library because I already did much on my program using directly udp. I can't use tcp because it's for a race 3d game. I think I will make something simple like counting server side the number of packet received and client side counting packet sent, and sometime sending to the client the result for him to know if to much of his packets are lost. |