Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

socket thread strategy

 
Manuel Cassel
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello !

For my assignement I chose to use the socket/thread strategy but I there's something I'm wondering.
First, I chose to implement the following model:
- one client connect
- the server instanciate a new single thread for handling all requests of this client
- the connection remains active until the client disconnects or the server is shutdowned

However, I could read on different post that some used the following model:
- one client connect
- the server instanciate a new single thread for handling a set of requests of this client (generally lock, update, etc..., unlock)
- and then the client disconnect. Thus, the connection between client and server is closed.

I'm a bit lost because I don't know which solution choose... from my point of view it's better to keep the first solution because it does not make many object to be created (one single thread, one socket).

Could you explain the mains pros and cons of which ?

thanks a lot !
 
Gilles Marceau
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Manuel,

if i understand correctly, you have chosen to use objects serialized over socket to implement your networking code (and not the RMI framework). It means you have to code the server entirely, and also how the server will deal with the threads.
First, i found this link that should be useful on this issue :
http://www.cim.mcgill.ca/~franco/OpSys-304-427/lecture-notes/node65.html
Secondly, in my opinion, the two approaches you mentioned (one thread per client, one thread per request) have another difference than the ones
explained in the link above, this is about the client identification.
If you use the "one thread per client" approach, it's easy to identify the
client requests in the server code (and also to synchronize on a client
basis), because the thread id is the client id. On the other hand, with
the "one thread per request" approach, you don't have the client identification out-of-the-box (you need to add a token id in the request, at least inside the server process). In that case, the thread often comes
from a thread pool created at server startup.
So, knowing if you need client identification in the server code can help
you to choose between the two approaches.

Hope it helps,

Gilles

PS : i used the RMI framework for my project, and in that case, there is no
choice to make, because this framework use a "one thread per request"
approach (the requests for a given client can be processed by
different threads on the server).
[ November 11, 2008: Message edited by: Gilles Marceau ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic