IP Packet length in Application Layer 1

[EWAN1]

I intend to use an IP based network for a control application. Control Messages (varying in length)of up to 8 bytes will be sent.

IP contains a length field but only for the IP packets not of the application message. If a message is split across IP packets how will my receiving node now how long the application message is and thus be able to re-assemble it?

Is this likely to cause problems in this application and are there any other ways round it other than specifying a length field in the application layer?

 

[pansophic]

If you are using TCP, then the packet should be reassembled prior to it passing up the stack. Your application should never be aware that a packet was fragmented at all. That is a big part of what TCP does, it ensures reliable connections so that the application doesn't have to worry about it.

This assumes that you are sending the message as a single packet initially.
pansophic

 

[EWAN1]

I'm using UDP, does this still apply?

 

[pansophic]

Yes, kind of. With UDP there is no guarantee that a given packet will be delivered, so you may well loose packets (but you should loose the complete packet, not a fragment of one).

If your packets aren't going to exceed 550 bytes, they probably won't ever be fragmented, even over a dialup link.
pansophic

 

[EWAN1]

Thanks a lot for your help!!

Can you set up the UDP protocol so that all application layer commands are sent in a single UDP frame. Each Frame of the same length?. and Bit stuff the spaces for shorter messages?

If the application commands span more than 1 UDP frame or more than one are in a UDP frame there will be problems i think.

 

[pansophic]

I've never done the UDP thing before, so I can't answer that for certain, but I would manually bit-stuff each send, so that I ensure that as data arrives, each X number of bytes is a frame.

You can do it simply by creating an array of FFs that are as long as the largest possible amount you would have to stuff and append this to the byte array or string that you are attempting to send, then just pull the left X number of bytes and send.

Or are you streaming?
pansophic

 

[EWAN1]

No i'm not streaming, that sounds like a good solution to me thanks a lot.
I'll investigate and find out if the bit stuffing can be done by the NIC loading the UDP frames to keep the application as simple as possible. Or it may be that there dosen't need to be any bit stuffing at all and UDP packets can vary in length but just ensuring that each command is sent as 1 packet.

watch this space.

 

[svermill]

It was already pointed out that UDP doesn't provide any reliablility. Also note that it doesn't provide for ordered delivery. Here is a cut-and-paste of the relevant portion of a capture file for UDP:

User Datagram Protocol, Src Port: netbios-ns (137), Dst Port: netbios-ns (137)
Source port: netbios-ns (137)
Destination port: netbios-ns (137)
Length: 58
Checksum: 0xa8dd (correct)

Port numbers but no sequence numbers. Compare to TCP:

Transmission Control Protocol, Src Port: netbios-ssn (139), Dst Port: 1214 (1214), Seq: 2931679140, Ack: 2493449355, Len: 0
Source port: netbios-ssn (139)
Destination port: 1214 (1214)
Sequence number: 2931679140
Acknowledgement number: 2493449355
Header length: 20 bytes
Flags: 0x0010 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 17520
Checksum: 0x281a (correct)

So UDP assumes that some higher layer handles reliability and ordering.

Regards.