Threads with Sockets in them? or Asynchronous Sockets?

[Ronodev.Sen]

the way my program needs to go is --

1) open a socket and listen on it
2) moment a client connects to the socket - process some data (by
sending it to another machine), get the result and send it back to the
SAME socket - the data isnt a large value (measured in bytes rather
than MB or GB)

i TRIED thinking of this in the Asynchronous way - BeginReceive - then
pass to the OnClient Connected handler, which calls a Wait For Data
function.

the way i see it , there's no way for me to tell WHICH socket is being
processed - which poses a problem since i also need to LOG any
successes / failures to TEXT FILE (not EventLog , sadly)
i'd have to write a whole NEW set of handlers to send the data BACK to
the socket.
if i call these functions from within the "WaitForData" function - i'd
PROBABLY be nixing the benefits of ASYNCHRONICITY... wouldn't i ?

on a cursory glance, would this appear to be a good candidate where i
process my own threads (keeping them in a synchronised arraylist) for
each socket , instead of taking the advantages of (what i understand
in my LIMITED knowledge so far) anonymous threads connecting to
anonymous sockets ???

thanks in advance!

 

[Guest]

Ronodev,
This kind of business scenario is a good candidate for Asynchronous socket
operations. You have a State object that can contain an instance of the
socket itself (or a custom stateobject class of your own design) which is
passed as a parameter.

You can retrieve this object in the callback (endrecieve) and therefore you
can gain access to the socket that pertains to the particular work item.
Peter

 

[William Stacey [MVP]]

Check this out:
http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf

I am using this pattern now for something and it seems to work very well.
After reading this, your design may be something like:
1) ReadStage - sync or async socket read pattern within the stage. Multiple
threads if blocking reads.
2) WriteStage - probably blocking writes ok here. Multiple threads.
Naturally, could use async socket writes as well.
3) LogStage - Do any logs here - single thread probably ok.
4) StateObject - includes TcpClient and any other shared state for client.
This passes between stages.
5) ServerStage - Your main server logic. Number of threads depends. One may
due. Probably no more then 1 + #CPUs.

It is a different design then what one would normally use with threaded or
async servers, but basically your just doing the async yourself, but all
your app logic feels like sync - so it is easy to reason about and you don't
have callbacks all over the place. Is also loosely coupled, which has other
advantages for your app over its life.

--
William Stacey [MVP]

| the way my program needs to go is --
|
| 1) open a socket and listen on it
| 2) moment a client connects to the socket - process some data (by
| sending it to another machine), get the result and send it back to the
| SAME socket - the data isnt a large value (measured in bytes rather
| than MB or GB)
|
| i TRIED thinking of this in the Asynchronous way - BeginReceive - then
| pass to the OnClient Connected handler, which calls a Wait For Data
| function.
|
| the way i see it , there's no way for me to tell WHICH socket is being
| processed - which poses a problem since i also need to LOG any
| successes / failures to TEXT FILE (not EventLog , sadly)
| i'd have to write a whole NEW set of handlers to send the data BACK to
| the socket.
| if i call these functions from within the "WaitForData" function - i'd
| PROBABLY be nixing the benefits of ASYNCHRONICITY... wouldn't i ?
|
| on a cursory glance, would this appear to be a good candidate where i
| process my own threads (keeping them in a synchronised arraylist) for
| each socket , instead of taking the advantages of (what i understand
| in my LIMITED knowledge so far) anonymous threads connecting to
| anonymous sockets ???
|
| thanks in advance!
|