Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Java : what is the difference between serversocket and datagramsocket?

Tags:

java

tcp

udp

Basically I am new to server and client programming in java , I google all the necessary resources to learn from this particular topic however I did not understand the difference between them.

What I Understand so far for these two is that Both of them can Handle Client Request, but I need to further know the benefits of each Class and what particular scenario or specific case where when can I used it efficiently.

Like for instance , I have a Server Client Program which is a subset of team-viewer in which The client program must send Screenshot to the server in every millisecond while the server is going to publish it from another connected client. The code is working but I found out ServerSocket consumes so much Heap although it delivers successfully to the servers and client as well. I also read a blog (The link is missing) that is related to my problem suggested that DatagramSocket is the solution because it does not execute Handshakes.

I am really concern of the Benefits and Disadvantage of these classes.

like image 486
neferpitou Avatar asked Dec 05 '22 04:12

neferpitou


1 Answers

A ServerSocket is for accepting incoming network connections on some stream protocol; e.g. TCP/IP.

A DatagramSocket is for sending and receiving datagrams on some connectionless datagram / message protocol; e.g. UDP/IP


Supplementary questions:

Basically what is a datagram

A datagram is bunch of information sent in a single logical packet. For example, a UDP packet.

and does this mean datagram = lightweight packets ?

It depends on your definition of lightweight!

UDP datagrams are sent as IP packets. If a UDP datagram is too big for an IP packet, it is broken into multiple IP packets by the sender and reassembled by the receiver.

and what does connectionless [mean],

It means that no logical connection exists between the 2 parties. If a component IP packet of a UDP datagram is lost, the UDP datagram is lost. The receiver never knows (at the application level). There is no reporting of data loss and no retrying in UDP. This is typical "connectionless" behavior.

does it mean Data might get lost during transmission?

Basically, yes. If you want reliable / lossless data transmissin the event that a datagram or on you should use ServerSocket and Socket; e.g. TCP/IP streams.

However, be aware that even with a (bare) TCP/IP stream, data delivery is not guaranteed:

  • If there is a network failure, or if either the sender or receiver has a failure, then a connection can be broken while data is in transit. That will result in data loss ... for that connection. (Sockets do not support reconnecting.) If the sender and/or receiver are still alive they will typically be informed that the connection has been broken, but they won't know why, or how much data was lost in transit.

  • It is possible for data to be corrupted in transit in ways that TCP/IP's error detection cannot spot. The receiver won't know this has happened.

Both of these issues can be addressed at the application protocol level; e.g. using message queues for the first and strong encryption and strong checksumming for the second.


Concerning your attempt to use ServerSocket.

The code is working but I found out ServerSocket consumes so much Heap although it delivers successfully to the servers and client as well.

You are doing something wrong. If you use the API appropriately the memory overheads should be insignificant.

My guess is that you are doing one or more of the following:

  1. Opening a new connection for each client / server interaction
  2. On the server side, creating a new thread for each connection
  3. Not closing the connections.

I also read a blog (The link is missing) that is related to my problem suggested that DatagramSocket is the solution because it does not execute Handshakes.

  1. Handshakes won't cause significant memory consumption.
  2. TCP/IP stacks don't typically do handshakes by default anyway.
like image 184
Stephen C Avatar answered Jan 13 '23 18:01

Stephen C