Opinion
Hi all,
I am trying to make a Server which responds to many clients using threads.
The client is to send a sentence to the server, and the server returns "OK" back to the client.
What is your opinion about the closing of the socket?
1. Shall I let the user decide when to connect and when to disconnect from the server? or
2. Shall I connect automatically, send the sentence, receive the OK and immediatelly close the connection..?
Leaving the socket connected would leave a running thread on the server until the user decides to disconnect while making the sending and receiving fast.... HOWEVER the 2nd option would make the connecting a disconnecting slower but would leave the server free from threads and would keep the resources available on the server..
What do you think? shall I leave it to the user hands or not?
THANKS :)
[887 byte] By [
Xenobiusa] at [2007-11-27 0:58:15]
Interesting question. More so since important information for a conclusive answer are missing.
1. Do you need some sort of session (e.g. for identifying the client) ?
2. How often and at which intervals are clients connecting ?
3. How many clients do you expect to connect ?
4. How large are the sentences you transfer ? (To evaluate the overhead of session opening / closing compared to the 'payload' of the transaction)
And there are surely a couple of questions more, that need to be answered before someone can answer the questions you pose ...
If you leave it in user hands to close connections, you should provide some sort of time out mechanism on the serverside, to make sure the server is not clogging up with unused threads.
If you do that, you must provide some failover functionality on the client side. And so on.
basically I would use the easy approach 'open, request, response, close ... '(like in http for example). If you need session handling, pass some sort of token from the server to the client during the first contact (like a session cookie in http) .
If you can make your server process transactional then it's probably a good thing to make it that way.
transactional means
receive connection
process
respond
close connection
This works if you have discrete jobs that work via request - response. Some applications, like chatting, are not transactional - if the server drops a client, there isn't really a way to get that person back.
So do the right thing
> 1. Do you need some sort of session (e.g. for identifying the client) ?
> 2. How often and at which intervals are clients connecting ?
> 3. How many clients do you expect to connect ?
> 4. How large are the sentences you transfer ? (To evaluate the overhead of session opening / closing compared to the 'payload' of the transaction)
Hmm well:
1. Yes so as to reply back
2. Not criticall
3. Maybe 50
4. 120 - 130 words
THANKS
