Sending UDP data question

[Guest]

Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Hi

If i send a block of data rx 50KB with udp (sendto) over an intranet , will
the receivers get all the blocks in order ?

Or will i have to design some extra protocol layer to solve this ?

Perhaps i am reinventing something, so give me a hint if something 'ready
for use' is avaible under CF .NET framework.

I assume that this 50kb will be sent as multiple UDP packets ,but will the
receiver get them in the same order as they where sent ?

Johan

 

[Guest]

Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

A single call to sendto should result in a single UDP datagram being sent
out. IP might fragment the datagram to fit in the MTU but on the receiver,
IP should reassemble the packet before indicating it to the application.

In general, however, it is a bad idea for an application to send 50K
datagrams because they will get fragmented.

--Amit

---
This posting is provided "AS IS" with no warranties, and confers no rights.

"Sagaert Johan" <REMOVEsagaert_j@hotmail.com> wrote in message
news:ucwyV6AHEHA.1272@TK2MSFTNGP12.phx.gbl...
> Hi
>
> If i send a block of data rx 50KB with udp (sendto) over an intranet ,
will
> the receivers get all the blocks in order ?
>
> Or will i have to design some extra protocol layer to solve this ?
>
> Perhaps i am reinventing something, so give me a hint if something 'ready
> for use' is avaible under CF .NET framework.
>
> I assume that this 50kb will be sent as multiple UDP packets ,but will the
> receiver get them in the same order as they where sent ?
>
> Johan
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

In article <#iSJrenHEHA.3896@TK2MSFTNGP11.phx.gbl>, "Amit Aggarwal [MSFT]"
<amitag@online.microsoft.com> wrote:
>In general, however, it is a bad idea for an application to send 50K
>datagrams because they will get fragmented.

And the chance of losing data goes up significantly with the number of
fragments.

If the probability of any one IP fragment successfully reaching its
destination is p, then the probability of getting all fragments out of N
fragments is p^N. Since 0<p<1, that means that as N gets larger, the total
probability of getting your data through shrinks.

Let's say you've got a horrendous path that drops one packet in ten.

Your chance of getting a packet through is 90%. Your chance of getting two
related fragments through is 81%. Your chance of getting three related
fragments through is 73%. If you've got 50k datagrams, let's be
charitable(*) and take the fragment size of 1500 bytes, giving 34 fragments
in all. Your chance that all the fragments get through, and you get your
datagram, is less than 3%.

Okay, so 10% packet loss is perhaps a little horrid. What about 1% packet
loss? With your 34 fragments, the chance of getting a whole datagram is
only 71%. You're losing more than a quarter of your data that way. And
what's criminally worse is that you're taking up nearly as much bandwidth as
if you were succeeding!

This is why TCP takes such pains to try and use segments (not fragments)
that are as large as (but no larger than) the PMTU. That does not mean,
however, that the window can't be significantly larger.

Alun.
~~~~
(*) Charitable, because the number taken as a maximum reliable path MTU was
usually given as 576. With those figures, the number of fragments in 50,000
bytes is 87, so the chance of a 50k datagram getting through a 10% loss
network path is .0001, and the chance of it getting through a 1% loss path
is under 42%.

[Please don't email posters, if a Usenet response is appropriate.]
--
Texas Imperial Software | Find us at http://www.wftpd.com or email
1602 Harvest Moon Place | alun@texis.com.
Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.