Re: Linux equivalent for ioctlsocket(FIONREAD) on datagram sockets

On Mar 10, 1:59 am, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
On Mar 9, 4:51 pm, already5cho...@xxxxxxxxx wrote:

Your line of thinking is not constructive. Your suggestions are
practically useless. It seems you're hanging on here not in order to
help other people but for sole purpose of massaging your own ego.
I'd greatly appreciate if you don't bother answering my questions in
the future.

You are welcome to be intentionally ignorant. But don't spit at the
people who are trying to help you.

The solution to your problem is this simple:

1) Set the socket non-blocking.

2) Don't worry about what happens when you send. The semantics for
blocking and non-blocking UDP sends are essentially the same. The only
difference is that a blocking send may silently discard a datagram
where a non-blocking send will return EWOULDBLOCK. You can simply
ignore EWOULDBLOCK or use it as an extra hint that the datagram
dropped.

DS

Now you are trying to be constructive.
However your concentration on the letter of standard prevents you from
understanding the spirit.
Yes, UDP is defined us unreliable. But it also defined as "best
effort". It would be practically useless without the later.
Now imagine the IP stack the adheres to both the letter and the spirit
of the standard. Imagine fast CPU/Memory/IO bus. Imagine slow physical
line. Please take into account that for modern CPUs/memory/IO-Bus even
1GBe is a "slow line". Imagine that fast CPU sends a burst of UDP
datagrams which is longer than SEND_BUFFER through blocking socket.
Now what the IP stack/packet driver that adheres to the "best effort"
spirit of UDP standard should do in that particular case? Drop the
packet? No way, that's against the spirit. The correct way would be
blocking a clling thread until the NIC hardware (probably through DMA)
reads one or more packets from socket's send buffer freeing up space
for the next one. Comprende?
I am absolutely sure that on Etherrnet 10/100 links all popular
general-purpose OSes behave exactly like described above. Didn't check
on faster links, but hopefully it's the same.


Now, if you really want to be constructive...
The original question is not particularly interesting. I'd ask a more
generic question:
What is the best way to receive fast UDP stream (order of 20K to 50K
packets per second) while dropping as few packets as possible?
On Windows the [pseudo]code presented in my original post easily
achieves packet error rate of ~1E-7 but hits the wall when we try to
do better. And on Windows when you hit the wall.... well, you hit the
wall.
On Linux (Ubuntu 8.10 x64) so far I see packet error rates in excess
of 1E-5. And yes, I tried both blocking and non-blocking sockets. Non-
blocking variant significantly reduces the CPU load but, at least on
fast computers, makes no material difference to the error rates. The
fact that the my current Linux results are so horribly bad leaves the
hope that I am doing something wrong... May be, I should try scatter-
gather read? Or something else?

I understand that quite a few people would try to suggest that I
shouldn't want :( to receive UDP datagrams at low error rate. All
these people are welcome to say it right here but sincerely I don't
promise a polite response.
.

Relevant Pages

  • Re: Determining if it is "safe" to send UDP packets
    ... for receiving Udp data. ... I'm receiving from a camera lines of data at 55 Hz. ... the next packet hits the wire. ... Another problem with TCP is its assumption that a lost packet is due to ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Incoherent E-mails
    ... The Novell crap was originally run on IPX ... The term in the early-mid nineties was "packet storm". ... The original advantage of UDP was ... > 60 bytes for TCP. ...
    (alt.computer.security)
  • Re: recvfrom() strange operation
    ... no matter what your network looks ... discover packet loss, partially loss and joinde packet and octett ... And the most important sfrtp working fine over TCP or UDP ... "frames" (or whatever you are calling your higher layer protocol ...
    (comp.os.linux.development.system)
  • RE: traceroute-like tool for UDP or TCP packet
    ... there is no UDP echo-request packet except against ... Linux traceroute sends UDP packets against high ports above 33000 and counts ... the ICMP Port-Unreachable. ... packet, ...
    (Security-Basics)
  • Re: Linux equivalent for ioctlsocket(FIONREAD) on datagram sockets
    ... blocking UDP socket without danger of being blocked. ... A non-blocking socket can always block. ... read the fourth packet, you hang. ...
    (comp.os.linux.development.apps)