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]
<Ronodev.Sen@gmail.com> wrote in message
news:1140614136.871293.6990@g44g2000cwa.googlegrou ps.com...
| 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!
|
