CODEWITHSUNDEEP
javasocketsserversocket
Matthias Hofmarcher
Matthias Hofmarcher

Reputation: 434

Use Socket permantently to handle Clientsession or create new one for every request

So i am quite new to Sockets and I have to create a Server-Client-App for school.

I expect a client to request something from the server multiple times during his runtime.

I am uncertain wether I should make a new java.net.Socket for every Request I get (Client opens new socket every time and Java Serversocket accepts) or use a single socket and keep that during the client's runtime.

Upvotes: 0

Views: 765

Answers (2)

Tobias
Tobias

Reputation: 2575

That strongly depends on how frequently the socket is used.

E.g. if you know that the client will send a request to the server every 50 milliseconds it would be easier to just keep the socket opened.

But if you know the client will only request information from the socket every 5 minutes it's probably better to close the connection and create a new one when needed. Same if you don't know when the next request will be created.

Creating a new Socket on server-side is not very expensive, so it's probably better to just close the connection if it's not used very frequently.

An exception could be a special socket, that needs authentication or other expensive stuff on creation, but that's probably not the case in a school project.

So in general: It depends on the usage of the socket, but if you're unsure whether it's used very frequently or not better close it and open it again when needed.

Upvotes: 1

Cara Ames
Cara Ames

Reputation: 275

Related to this question:

Maximum number of socket in java

If you're worried about exceeding the maximum number of sockets that can be opened (I imagine this is highly unlikely in your case) you can create a work-around where you use TCP to initially establish the connection, send the client a UID (Unique Identifier, a 64-bit unsigned long long type should be sufficient) and then close the TCP connection. Fill and maintain a structure (or Class object in your case) detailing the connection details (IP address, Unique Identifier code) and then wait on arriving packets sent via UDP (User Datagram Protocol, an alternative to TCP). If you decide to use UDP, be aware that you'll need to implement a means of reordering packets in order to reconstruct a byte-stream (serialisation) and a mechanism for resending data packets if somehow they do not arrive (packet loss recovery).

Sounds worse than it is. I'll repeat though, don't bother yourself with these intricacies if you're not worried about exceeding any limits.

Upvotes: 1

Related Questions