2

I have to do a bittorrent application project in Java, and it require to transport data by UDP protocol, not TCP. In this project, the teacher asks me to assure the reliability in UDP protocol. So I have searched some solutions on the internet and found that in java, there are classes such as "ReliableSocket" and "ReliableServerSocket". So I'd like know that these classes can satisfy my project's requirement. And what are the differences between these two classes ?

Thanks a lot for your help

Lee Dat
  • 155
  • 1
  • 6
  • 20
  • Tcp is a reliable protocol, meaning the protocol is reliable and that is abstracted from the application level which is encapsulated. Udp is not and so first applying some ordering to the packets or session (no such thing as a session in udp, you have to create that in the application layer) so that it is possible to assemble out of order received packets and detect dropped packets and have them resent. Basically all the things Tcp does for you efficiently and neatly abstracted away from you, you have to do. I would say why not just use Tcp? Seems like a poor use of existing technology. – marshal craft Dec 25 '16 at 09:36
  • Also believe google has done their own version of Udp called Quick, which I think is intended to be a higher performance replacement for tcp, though I'm not sure of the specifics of Quick, as it isn't a internet standard as tcp and udp are. But if it's done by google there probably is/are some nodejs packages for it. – marshal craft Dec 25 '16 at 09:38
  • Is this Oracle Java or javascript? I assume Oracle Java as of now. – marshal craft Dec 25 '16 at 09:47

1 Answers1

1

UDP is a a lossy unreliable protocol which runs on top of the IP protocol. Unlike TCP (which handles all aspects of reliable communication) it is up to the application layer to handle dropped packets and other aspects of a "reliable" transport protocol. As such it is likely that any implementation which requires reliability to similar extent as that given by TCP will occur additional overhead.

You could set aside two ports port A and port B. Each port is unidirectional unless there is a dropped packet.

client 1 = port A = server 2

server 1 = port B = client 2

This keeps things simple. Server simply sends data and listens periodically but only receives messages if it's client drops a signal.

The client is the negation. It receives signals and only sends if it is missing a packet. An alternative implementation would be one in which the client/server pair could talk to each other, making the port truly unidirectional.

We get message reliability on both ports by using two packet index.

client index 1 = server index 2

server index 1 = client index 2

The index for each are single byte and incremented by the clients when they send a new message. Message delivery is assumed until reception of a special message which would be a UDP message for dropped packet. It would contane the signal for dropped message probably in it's most significant or least significant bit/byte depending on the endianness of the design as well as the index of the message. A queue also seems to be necessary but I have not worked the details of that out yet.

marshal craft
  • 439
  • 5
  • 18
  • My data can be in any type like byte[], int, String, java object or an Object that I create. So when we want to transfer data by UDP, we must convert my data type into byte array, and bind it to the DatagramPacket. But DatagramPacket doesnot assure the reliability, I sometimes lost my packet. – Lee Dat Dec 25 '16 at 09:55
  • So I would like to know if java does support some available mechanism to transfer the data with reliability. Your idea is good, but we have to program by ourself. – Lee Dat Dec 25 '16 at 09:58
  • Yes you do have to program it yourself. Really if you want reliablillity you should use TCP it was designed to be reliable. The one draw back to TCP is it recognizes clients and servers. So normally two ends, one does all the asking and the other simply answers those requests. I don't want to get into Network address translation but there tends to be issues when the server wants to act as a client. One solution to this is WSS or a web socket which makes Tcp more like Udp in that both sides can act as a client. – marshal craft Dec 25 '16 at 10:18
  • There is Google's Quic protocol which has been submitted for adoption as a new formal internet standard like UDP (after reading more about it I guess it just brings TSL (ssl) to UDP. Which is odd because the TSL specification already outlined UDP. I read that QUIC handles dropped packets "well" whatever that means. You can almost certainly find and use a java QUIC socket api. – marshal craft Dec 25 '16 at 10:20
  • Is it necessary to use timeout in this case ? After an interval, if the client doesn't receive the data, that means it is lost, so the server must resend. – Lee Dat Dec 26 '16 at 14:55
  • @ABCDE in what case? In UDP there is no such thing as a connection and thus can not time out as is the case of TCP. If you are referring to QUIC I can not say as I do not have experience with that transmission protocol. – marshal craft Dec 27 '16 at 20:41
  • I think there is two sides to your question. An academic side in which you learn about internet transport protocols and packet encapsulation/encoding and a real life commercial product side. On one side it is good exercise to undertake, you could completely and easily implement application software to make UDP reliable. Maybe even with less overhaul and higher bandwidth than TCP? On the other side, TCP is an international standard for reliable transmission and probably does it very well. Maybe even it is optimized to be the best solution given it's level of reliability. – marshal craft Dec 27 '16 at 20:44
  • As such it may be a futile effort to design your own implementation which essentially mimics TCP. Also TCP has an advantage that it does everything on the IP level so you just send packets and everything is handled efficiently on it's own. UDP exists on the IP level so your dropped packet handling would be encapsulated into the payload of a UDP packet rather than a optimized header. – marshal craft Dec 27 '16 at 20:46
  • Google may have developed QUIC because it needed an improved performance medium other than TCP. Basically it did not require all the reliability of TCP but more than UDP. As such it may have been that an performance gain was possible. For instance real time video if a packet is dropped than no need to try and get it, but maybe it needs some kind of tracking making it a "semi-lossy" transmission medium. Strangely though I read QUIC runs OVER UDP instead of simply running as it's own protocol over IP. So QUIC is just an application inbetween IP/UDP and your application. – marshal craft Dec 27 '16 at 20:52
  • Also I have tended to notice that while google does great when it comes to things which lay on a very high level of abstraction such as a browser developed in python or a web server, all things which require bright imaginative ideas; it's often flashy hotshot developers tend to fail in other areas often close to hardware, utilizing international multi-conglomerate cooperation and just about anything which exists typically low in a large complex and often asymmetric hierarchy of abstraction and complexity mitigation where other company's typically signaled by Microsoft's presence have dominated – marshal craft Dec 27 '16 at 21:02
  • typically these fields are dominated by necessity and this is the reason they are asymmetrical and imaginative ideas simply don't work. For example given a discrete list of object's which set out to define the word "reliable" there is a very well defined optimal solution. – marshal craft Dec 27 '16 at 21:06