 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2005Java Datagram Question
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 ? >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.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >> The question is what happens when the server is in the "receive()" >> method when this problematic datagram is received ? [quoted text clipped - 5 lines] > 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 On Sun, 25 Dec 2005 21:23:59 +0000, Steve Horsley <steve.horsley@gmail.com> wrote, quoted or indirectly quoted someone who said : >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? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > 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 Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e >Note >that ethernet is not routed. Don't smart hubs route between electrically separate LANs? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > 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 Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e > 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? SignatureKnute Johnson email s/nospam/knute/ >> Neither IP nor UDP support retransmission. A dropped or damaged >> fragment will cause the entire IP datagram, and consequently the UDP [quoted text clipped - 5 lines] > > If it arrives whole though, it is guaranteed to be free from error? No. You need some kind of checksum - or just use TCP. SignatureLTP :) On Mon, 26 Dec 2005 11:53:18 -0700, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >> If it arrives whole though, it is guaranteed to be free from error? > >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 SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > 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 Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e > 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 Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e >>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. 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. >>> Does a Datagram ever consist of more than one physical network >>> packet? Could it ever be more than one physical Ethernet packet from [quoted text clipped - 5 lines] > 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. > 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 Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e > 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. > Hello, > [quoted text clipped - 6 lines] > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.