Re: Determining if it is "safe" to send UDP packets

From: Pavel A. (pavel_a_at_NOwritemeNO.com)
Date: 01/30/05 

Date: Sun, 30 Jan 2005 04:47:02 -0800

IMHO for "reliable" UDP you need to use some Quality of service
approach.
Maybe your network is QoS enabled and your traffic gets classified as "below
best effort"?

The future Microsoft OS is going to be cooperative with apps to discover
actual
network characteristics - see this -
http://www.microsoft.com/whdc/device/stream/qWave.mspx

Regards,
--PA

"Spiro Trikaliotis" wrote:
> Hello Roger,
>
> thank you for your answer.
>
> Roger Levy <rhl@i3e.org> wrote:
>
> > I could be glib and say the answer is TCP but I assume you have good
> > reasons for using UDP.
>
> Yes, we have. We want to transfer images obtained from a camera as fast
> as possible over a wireless link. The protocol used is tolerant of
> packet losses, thus, it is not a big problem if the one or the other
> packet does not get received.
>
> Every image is packed. Unfortunately, the packed images appear almost
> all at the same time. That's the reason why we have to send them out in
> bursts.
>
> As we are sending on a (direct) wireless link (but assuming we are the
> only one sending anything), we do not need to take into account any
> potential problem like congestion, routers that add processing delay, or
> the like.
>
> For testing purposes, we tried to connect two machines via fast
> ethernet, utilizing a cross-connect cable. Thus, we are sure that it is
> the sender's OS that is throwing the UDP packets away.
>
> > I think a possible answer to determining when it is "safe" to send is
> > to automate the process that you have described as a "training"
> > process that takes place before sending important data. Training is
> > essentially what modems do to determine the highest reliable data
> > rate. Training would require you to define a message protocol that
> > enables the destination machine to detect when training is is being
> > executed and how to respond to it. The complexity of such a scheme
> > would probably lead me back to TCP.
>
> As real-time is a major issue, TCP or a similar approach is obviously
> out of scope. Furthermore, as I told before, we do not need each and
> every packets. Anyway, getting only the first 10%, and nothing
> aftermore, is *not* enough for us.
>
> It is very interesting to see the scheme of the packet losses if you
> just send out a burst: The first x% of packets are all send. Then, the
> next 100%-x% are not send, they are almost all completely lost. After
> this, again x% are send, and so on. It really looks like a full buffer
> on the sender's site.
>
>
> Another problem with TCP is its assumption that a lost packet is due to
> a congestion (which is not true in our case, as we do not have
> congestions), but lost packets are rather frequent on the wireless link.
>
>
> > Another approach is to make your UDP path more reliable but you
> > haven't given enough network topology for anyone to tell you where to
> > start.
>
> Well, we have A, and we have B, connected directly via the wireless
> link. It cannot be more simple, can it? ;-) BTW: We need a datarate of
> not more then 150 KB/s on the wireless link - a data rate which it can
> surely handle. Furthermore, our protocol is not allowed to perform any
> handshaking. The receiver is fast enough (this is know before-hand).
>
>
> > Recently I shifted to Linux for this problem because I felt there was
> > more tunability available.
>
> BTW: We have exactly the same problem with Linux. ;-) Only our own
> drivers in RT-Linux give us full control, and there, it works.
>
>
> > My belief is that you are tackling a problem that is ripe for
> > optimization but you need to understand that the potential for errors
> > or lost data will always exist with UDP.
>
> Yes, we are fully aware that the potential for errors or lost data is
> always there with UDP. In fact, that's exactly what we want. ;-)
>
> Anyway, we do not want the kernel to "unnecessarily" throw away some
> packets on its own. At least, we want to be informed of this process, so
> we can react.
>
> Thank you for your input,
> Spiro.
>
> --
> Spiro R. Trikaliotis
> http://www.trikaliotis.net/
>

Relevant Pages

  • Re: Update: UDP 770 Potential Worm
    ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
    (Incidents)
  • Re: Overhead, UDP: Many packets on 1 socket vs. one packet and many ?sockets.
    ... a gigabit LAN network using UDP. ... into "frames" and each device frame is a single UDP packet. ... information in the data packets. ... over each of those sockets. ...
    (comp.unix.programmer)
  • Re: em driver sending bad packet lengths
    ... This is from UDP NFS ... Here is a tcpdump trace showing some bad packets: ... 258 broadcast/multicast datagrams undelivered ... device = 'PRO/1000 EB Network Connection' ...
    (freebsd-net)
  • Re: Need a script to understand names posts
    ... the physical layer of the ISO model, augmented by providing all of the logic ... a network model that does more than just detect the fact that packets ... and brings them back onto the network as if they had never been lost. ... the packets previously lost will never ever be lost again, ...
    (microsoft.public.scripting.wsh)
  • Re: Determining if it is "safe" to send UDP packets
    ... As we are sending on a wireless link (but assuming we are the ... the sender's OS that is throwing the UDP packets away. ... Another problem with TCP is its assumption that a lost packet is due to ...
    (microsoft.public.win32.programmer.kernel)