DataReceived type event for tcpclient network stream?

  • Thread starter Thread starter JamesB
  • Start date Start date
J

JamesB

I have a service and a client forms app - I want to be able to have the
service send data back to the client app intermittently, and I've
established a connection between the two using tcpclient.
What I can't see is any sort of event I can use that will be triggered when
data is received at the client. Is there such a thing?
Or should I create a separate "listening" thread that polls the connection
for data and then triggers whatever I need to happen? Or is there a better
way?

Thanks!
 
I have a service and a client forms app - I want to be able to have the
service send data back to the client app intermittently, and I've
established a connection between the two using tcpclient.
What I can't see is any sort of event I can use that will be triggered when
data is received at the client. Is there such a thing?
Or should I create a separate "listening" thread that polls the connection
for data and then triggers whatever I need to happen? Or is there a better
way?

Thanks!
Click to expand...

Hah, using network, tcpip... hahaha... that wont work... neither I
will google have that ansver, nor usse msdn, just give up... pick up a
RS-232 manual, or maybe a disc, mailing in that between tha PC:s.

No, there is lots of examples how you should do it, it depends on what
you are going to do in the future that holds me back. a point to point
is good for a while, then it gets into a hub-and-spoke and after a
while you are looking for a ESB solution and integrating that to an
already established SOA architecture migrating from UDDI to whatever..
no I wont go there...

Stay away from tcpip.. networks... evil, EVIL I say... ;)
 
JamesB said:
I have a service and a client forms app - I want to be able to have
the service send data back to the client app intermittently, and I've
established a connection between the two using tcpclient.
Click to expand...

So you presumably have a Listener in the service, waiting for a call from the
client...
What I can't see is any sort of event I can use that will be
triggered when data is received at the client. Is there such a thing?
Click to expand...

Seems like a mirror image setup would work: your client app also sets up a
listener, and the service calls it when it has some stuff...
 
I have a service and a client forms app - I want to be able to have the
service send data back to the client app intermittently, and I've
established a connection between the two using tcpclient.
What I can't see is any sort of event I can use that will be triggered
when data is received at the client. Is there such a thing?
Or should I create a separate "listening" thread that polls the
connection for data and then triggers whatever I need to happen? Or is
there a better way?
Click to expand...

IMHO, the "best" way is to use the async API, which provides something
sort of like events, albeit with a bit more complexity. It works in a
very similar way though, at least when you are using the callback aspect
of it.

In particular, the various classes -- TcpClient, NetworkStream, Socket --
include methods that start with the word "Begin" or "End". These methods
all represent an asynchronous version of a synchronous method. You start
by calling the "Begin" method, and when the operation completes, you are
notified via some mechanism at which point you call the "End" method,
providing your own code with the results of the operation.

The standard .NET async model provides three different ways to know that
an operation is completed: IAsyncResult.IsCompleted property, which you
can poll (generally the wrong thing to do); IAsyncResult.AsyncWaitHandle
property, which you can wait on (better than polling, but blocks a thread
and so doesn't usually wind up better than just dedicating a thread using
the synchronous method); and a callback delegate, which you provide when
you call the "Begin" method, and which is called when then operation has
actually completed.

The last technique is IMHO the best, and it's pretty much the same
behavior that an event would provide. The main differences being that you
pass the delegate to a method (the "Begin" method) rather than adding it
to an event, and that because of that you can only have one delegate
"subscribed" to the "event" at a time.

Pete
 
Back
Top