Re: Determining if it is "safe" to send UDP packets
- From: "GrkEngineer" <GrkEngineer@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 14 Jun 2006 04:13:53 GMT
Gregory_May,
I've been struggling with C++ .Net and both the UdpClient and socket classes
for receiving Udp data. I'm receiving from a camera lines of data at 55 Hz.
Each line contains 1024 pixels with 64 bands (shorts) each pixel. Along with
each line are two doubles per pixel. Is it possible to read this Udp data in
..Net. I've been able to receive lines using straight C code in windows and
linux. But I'm trying to use C++/CLI .Net to display data using DirectX.
Please help. Thanks.
"gregory_may" wrote:
In my case, I had to build some test programs that sent & received packets..
I actually had to do a fair amount of work fine tuning the receiving client
application ... I finally went with the .Net thread pool. Using the thread
pool in .Net probably increased my Frames/Second at least 25%. I also had
several thread concurrency & memory management issues on the broadcasting
program to nail down. Some of which only showed up sporadically & under
load.
My suggestion for both the client & broadcasting program is to rip open the
comm layer (at the lowest level) & put timing checkpoints so you can see at
what time messages go out & in of your program. This was the only way I
could tell what was going on.
"gregory_may" <None> wrote in message
news:%23G2ok0UDFHA.2620@xxxxxxxxxxxxxxxxxxxxxxx
I am currently developing an application that uses UDP for broadcasting
images. I have parameters that let me "Tune" how long I must wait before
the next packet hits the wire. In my application, a 50 ms delay between
sends has proved to be the best compromize between speed & reliability.
In my testing, going below this threashold actually can blow up the
network driver on the receiving machine!
So, you might try just to add a basic delay to make sure the next paket
doesnt go out too soon.
Good Luck!
g.
"Spiro Trikaliotis" <news-200501@xxxxxxxxxxxxxxx> wrote in message
news:slrncvpg5a.8uh.news-200501@xxxxxxxxxxxxxxxxxxxxxxx
Hello Roger,
thank you for your answer.
Roger Levy <rhl@xxxxxxx> 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/
- Prev by Date: Re: Setting system startup time?
- Next by Date: POSAO
- Previous by thread: Working of EnumWindows
- Next by thread: POSAO
- Index(es):
Relevant Pages
|
