Re: Deaf CAsyncSocket on Windows Service.
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Tue, 20 Jan 2009 14:35:36 -0500
Note that for UDP, your network stack is free to discard, at any time, for any reason
whatsoever, any UDP packet. Any router, anywhere along the path, is free to drop a packet
with no notification to sender or receiver. Therefore, if you think there is a 1:1
correlation between UDP packets sent and UDP packets received, you are in serious trouble.
There is NO SUCH REQUIREMENT. In fact, if I send UDP packets A, B and C in that order,
ANY of the following sequences are VALID as defined by the UDP protocol:
{} {A, B, C} {A C B} {B A C} {B C A} {C A B} {C, B, A} {A} {B} {C} {A B} {A C} {B A} {B
C} {C A} {C B} {A A A B B} {A B A C A B A} ...(sorry, it is an infinite set and I'm not
going to type out each one)
To believe anything else is delusional. UDP does not guarantee delivery, does not
guarantee order of delivery, and does not guarantee that you will not receive duplicate
messages. Messages are limited to 512 bytes of data (536 bytes total, including IP
datagram header). If you do a receive of fewer bytes than the UDP message, the remainder
of the UDP message can legitimately be discarded. A UDP message longer than 536 total
bytes can be truncated without any notification that it has been truncated. Often a UDP
packet will be truncated to the MTU size of the underlying transmission mechanism, that
is, 1518 bytes (including header) on Ethernet, Some other layers have shorter MTUs.
Therefore, some people have been able to send longer-than-512-byte data packets between
two machines on their desktop, but as soon as the packet hits a router it is truncated. A
change in a network card can change this. The only guarantee is that a packet will not be
truncated below 536 total bytes, but you still don't have a guarantee that the packet will
get there, get there in order, or get there only once.
UDP can ONLY effectively be used for multicasting and broadcasting, very rare and limited
situations. UDP packets are often blocked by firewalls as a policy decision by a
sysadmin. UDP has no flow control built in, and you can flood networks and routers with
UDP packets and they will merely be discarded upon receipt (it is a form of
Denial-of-service attacks). UDP is almost always a poor choice for communication.
Therefore, if you want reliability, you must not use UDP.
joe
On Mon, 19 Jan 2009 20:51:47 -0800, Tim Roberts <timr@xxxxxxxxx> wrote:
"Ricardo Vazquez" <rvazquez@xxxxxxxxx> wrote:Joseph M. Newcomer [MVP]
This is my problem:
On an application of mine, which is a Windows Service, developed with VC++
6.0, I use an UDP CAsyncSocket derived class.
...
What I do then is to programmatically restart the service; but some
datagrams have been lost. And this is a major problem for me.
Well, then you are already screwed. UDP does not guarantee delivery. You
could lose datagrams at any time, without notice.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Prev by Date: Re: Deaf CAsyncSocket on Windows Service.
- Next by Date: Re: CMenu from SubMenu
- Previous by thread: Re: Deaf CAsyncSocket on Windows Service.
- Next by thread: Crash using C++/CLI to let MFC use .Net
- Index(es):
Relevant Pages
|
