471,316 Members | 1,660 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,316 software developers and data experts.

Threads with Sockets in them? or Asynchronous Sockets?

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!

Feb 22 '06 #1
2 2029
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

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Ro*********@gmail.com" wrote:
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!

Feb 22 '06 #2
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]

<Ro*********@gmail.com> wrote in message
news:11********************@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!
|
Feb 22 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Zunbeltz Izaola | last post: by
14 posts views Thread by Michael C | last post: by
2 posts views Thread by Stressed Out Developer | last post: by
15 posts views Thread by Bryce K. Nielsen | last post: by
7 posts views Thread by Brendon Costa | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.