I've got a Windows application that receives and processes XML messages transmitted via UDP. The application collects the data using Windows "raw" sockets, so the entire layer 3 packet is visible.
We've recently run across a problem that has me stumped.
If the XML messages (i.e., UDP packets) are large (i.e., > 1500 bytes), they get fragmented as expected. Ordinarily, this will cause the XML processor to fail because it attempts to process each UDP packet as if it is a complete XML message. This is a known short-coming in the system at this stage of its development.
On Windows 7, this is exactly what happens. The fragments are received and logged, but no processing occurs. On Windows XP, however, the same fragments are seen, and the XML processor seems to handle everything just fine.
Does Windows XP automatically reassemble UDP fragments? I guess I could expect this for a normal UDP socket, but it's not expected behavior for a "raw" socket, IMO. Further, if this is the case on Windows XP, why isn't the behavior the same on Windows 7? Is there a way to enable this?
Best Answer
it sounds like the bug is in the way the XML processor is obtaining the UDP datagrams. It should not be looking at packets at all. That's the UDP stack's job.
The XML processor should be asking the UDP layer for re-assembled UDP datagrams. Splitting datagrams into packets and then reassembling those packets into datagrams is the IP and UDP stack's job.
Obviously, if you use raw sockets, UDP will break if you don't replicate this behavior. But don't use raw sockets, use UDP that way it was intended to be used.
When you intercept packets through the raw interface, whether you get them before or after IP reassembly depends on a number of system parameters such as what firewalls are enabled and what rules they have. Your code "happens to work" if it gets the raw packets after IP re-assembly. But relying on this is broken. if re-assembly is not needed, it will not happen, and it is not always needed.