Java Datagram Question

[yuvalste]

Hello,

I'm writing a server side (in JAVA) that is receiving UDP Datagrams
from clients.
Say a client sent to the server 1 packet, but for some reason the
packet was not fully received, and after a while another packet was
send from another client.

The question is what happens when the server is in the "receive()"
method when this problematic datagram is received ?

 

[Roedy Green]

The question is what happens when the server is in the "receive()"
method when this problematic datagram is received ?

the JavaDoc says receive blocks until a packet is received. I would
image then that if a malformed packet arrived the hardware would not
even pass it on from the buffer in the Ethernet card hardware, and if
anything malformed or incomplete did make it into the Datagram packet,
you would not see it, because it would be overwritten by a subsequent
good packet before receive returned. I suppose if you got a timeout
before a good packet arrived you could have junk in your Datagram
packet.

I wonder if there are tools for testing things like this. In the old
days of you could simulate a bit of line noise on a modem.

 

[Alun Harford]

Hello,

I'm writing a server side (in JAVA) that is receiving UDP Datagrams
from clients.
Say a client sent to the server 1 packet, but for some reason the
packet was not fully received, and after a while another packet was
send from another client.

The question is what happens when the server is in the "receive()"
method when this problematic datagram is received ?

UDP guarantees data integrity.

Alun Harford

 

[Steve Horsley]

the JavaDoc says receive blocks until a packet is received. I would
image then that if a malformed packet arrived the hardware would not
even pass it on from the buffer in the Ethernet card hardware, and if
anything malformed or incomplete did make it into the Datagram packet,
you would not see it, because it would be overwritten by a subsequent
good packet before receive returned.

This is exactly right. Either the whole intact packet will be
received, or nothing will be received.

I suppose if you got a timeout
before a good packet arrived you could have junk in your Datagram
packet.

No. Because a malformed packet is discarded by the lower layers,
any timeout, wherever you set it, will simply timeout as though
no packet was ever received. Unless your own application code
fails to handle a timeout properly.

Steve

 

[Roedy Green]

No. Because a malformed packet is discarded by the lower layers,
any timeout, wherever you set it, will simply timeout as though
no packet was ever received. Unless your own application code
fails to handle a timeout properly.

I'd like to see proof of that before I trusted it. You give receive a
handle to YOUR DataGram packet. If it uses it for a buffer it could be
malformed at timeout time unless the low layers at that point cleared
your DataGram.


On the other paw, there is no reason for you to look at that DataGram
unless receive returned normally.

Does a Datagram ever consist of more than one physical network packet?
Could it ever be more than one physical Ethernet packet from the
router?

 

[Gordon Beaton]

Does a Datagram ever consist of more than one physical network
packet? Could it ever be more than one physical Ethernet packet from
the router?

Yes.

Ethernet frames cannot carry more than 1500 bytes of payload. Note
that ethernet is not routed.

IP datagrams can hold up to 65536 bytes of payload. IP datagrams
larger than the MTU of the link layer are fragmented and sent in
multiple link data units (such as ethernet frames, but realize that
ethernet is not the only link protocol that might be used by IP).

UDP datagrams can be up to 65536 bytes long (header + payload). Each
UDP datagram maps onto one IP datagram, which is broken into as many
fragments as needed by the link layer at each link along the route.

Neither IP nor UDP support retransmission. A dropped or damaged
fragment will cause the entire IP datagram, and consequently the UDP
datagram, to be dropped.

/gordon

 

[Roedy Green]

Note
that ethernet is not routed.

Don't smart hubs route between electrically separate LANs?

 

[Gordon Beaton]

Don't smart hubs route between electrically separate LANs?

There are switches that can also route, but switching and routing
occur at different layers in the protocol stack.

/gordon

 

[Knute Johnson]

Neither IP nor UDP support retransmission. A dropped or damaged
fragment will cause the entire IP datagram, and consequently the UDP
datagram, to be dropped.

/gordon

Gordon:

If it arrives whole though, it is guaranteed to be free from error?

 

[Luc The Perverse]

Gordon:

If it arrives whole though, it is guaranteed to be free from error?

No. You need some kind of checksum - or just use TCP.

 

[Gordon Beaton]

If it arrives whole though, it is guaranteed to be free from error?

AFAIK yes. At any rate as correct as the optional (!) UDP checksum can
guarantee, as well as the checksums of the underlying link layers.

The algorithm is described in rfc1071 if you're interested in reading
more.

/gordon

 

[Roedy Green]

No. You need some kind of checksum - or just use TCP.

There is a checksum already in the UDP header. That should be
sufficient.

The headers are protected by checksum by the IP protocol, but not the
body of the message. I gather the idea is the intermediate packet
handling routers need good headers, but don't really care about the
body. That can be handled with a separate checksum end to end.

I suppose if IP were being designed today the checksum would cover the
entire packet, but at the time it was invented, that calculation was
expensive.

see http://mindprod.com/jgloss/ip.html
http://mindprod.com/jgloss/udp.html

 

[Gordon Beaton]

I suppose if IP were being designed today the checksum would cover
the entire packet, but at the time it was invented, that calculation
was expensive.

Doubtful, since the current implementation intentially allows
intermediate routers to perform additional fragmentation to individual
fragments, without having to recalculate anything.

/gordon

 

[E.J. Pitt]

I'd like to see proof of that before I trusted it. You give receive a
handle to YOUR DataGram packet. If it uses it for a buffer it could be
malformed at timeout time unless the low layers at that point cleared
your DataGram.

The proof is in the RFC. A datagram is received completely or not at
all, and the RFC determines the behaviour of the transport layer,
several layers below Java.

 

[E.J. Pitt]

Yes.

From the remainder of the reply this should clearly be 'No'. Once a UDP
datagram has been fragmented it is nobody's responsibility to reassemble
it so it will be lost.

 

[Steve Horsley]

From the remainder of the reply this should clearly be 'No'. Once a UDP
datagram has been fragmented it is nobody's responsibility to reassemble
it so it will be lost.

The answer is Yes. There would be no point in fragmenting packets
ever if fragments were always discarded.

It is the responsiblity of the receiving device's IP stack to
reassemble fragments into complete IP datagrams. The IP stack
implements a reassembly timer that will give up and discard all
collected fragments collected so far if the rest does not arrive
in a reasonable time. All the applications above the IP layer,
including the JVM) will either be given the completed datagram,
or nothing.

Normally, no reassembly is performed anywhere in the path between
sender and recipient, but some firewalls will reassemble in order
to more thoroughly check a packet's content. Some attacks involve
splitting a bad payload between fragments to try and hide the
true content from simple firewalls.

 

[Gordon Beaton]

Once a UDP datagram has been fragmented it is nobody's
responsibility to reassemble it so it will be lost.

Unless "Don't fragment" is set, IP will fragment any datagram larger
than the MTU and it will be reassembled by IP at the recipient.

What fragmentation are you referring to, for which there is no
corresponding reassembly?

/gordon