473,842 Members | 1,601 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Async TCPClients

Hi all,

Three questions really:

1) The async call to the networkstream's endread() (or even endxxx() in
general) blocks. Async calls are made on the threadpool - aren't we advised
not to cause these to block?

2) You can connect together a binaryreader to a networkstream:

BinaryReader reader = new BinaryReader(st ream);

And then read an int from it:

int i = reader.ReadInt3 2();

And vice versa.

Since there are no calls to beginread/endread, I presume this isn't a
synchronous call. Is there any way to make it async? Or am I missing the
point?

3) I'm trying to implement the message mechanism described here:

http://msdn.microsoft.com/library/de...rp09182003.asp

In order to answer question 2), I'm going to read the the messagetype
asynchronously, but the rest of the message synchrounously in the callback
(by tying together the binaryreader and networkstream). Is it a good idea to
do mix the two like this? What happens if the network lags, or bytes go
missing?

Thanks!

Shak



Jun 19 '06 #1
6 3828
Hi Shak,

I've submitted some answers to your questions in-line
1) The async call to the networkstream's endread() (or even endxxx() in
general) blocks. Async calls are made on the threadpool - aren't we
advised
not to cause these to block?
If you are worried about blocking a ThreadPool thread then spawn your own
Thread and use synchronous NetworkStream calls.
But I wouldn't worry about it anyway. Just don't call EndRead while on a
ThreadPool thread because nested ThreadPool calling may cause a deadlock.
i.e. don't execute asynchronously on a ThreadPool thread to make another
asynchronous call on another ThreadPool thread (this may cause a dead-lock).
2) You can connect together a binaryreader to a networkstream: .... Since there are no calls to [BinaryReader's] beginread/endread, I presume
this [is] a
synchronous call. Is there any way to make it async? Or am I missing the
point?
BinaryReader works synchronously. If it's used in an asynchronous callback
then it's being used asynchronously within the context of your application.
In other words, Async callback --> Sync ReadInt32() means that the
ReadInt32() call is now asynchronously executing on a ThreadPool thread.

If my explanation doesn't work for you than please tell me what is the
architecture you are trying to achieve?
3) I'm going to read the the messagetype
asynchronously, but the rest of the message synchrounously in the callback
(by tying together the binaryreader and networkstream). Is it a good idea
to do mix the two like this?
I recommend the following approach for a very simple RPC app:

1. Provide an internal AsynchronousCal lback to the BeginAcceptTcpC lient on
the TcpListener (server-side).
2. In your private AsynchronousCal lback method call EndAcceptTcpCli ent and
grab the TcpClient that has connected.
3. In a loop call AcceptTcpClient (synchronously) if desired while in the
AsynchronousCal lback after handling the current connection.
3. Authorize TcpClient.Remot eIPAddress to access your application.
4. TcpClient.GetSt ream() and wrap it with a NegotiateStream for NTLM or
Kerberos authentication (AuthenticateAs Server)
5. On the client-side's TcpClient use must also use NegotiateStream with the
same arguments (AuthenticateAs Client)
6. Because your TcpClient on the server-side is referenced in a method that
is executing asynchronously you should use synchronous calls to read from
the NegotiateStream . Using a BinaryReader that wraps the NegotiateStream
call BinaryReader.Re ad*
7. This is beginning to look a lot like Remoting. For this reason it makes
sense to use IMessage implementations as your remote call objects and the
..NET framework will provide the tools to do so.
8. I have implemented my own Remoting framework for more control and to
gather experience. In my implementation I have a class that handles all
network communication. The class automatically sends an Int32 to the remote
counter-part that is the length of the serialized IMessage implementation
before sending the actual IMessage. In the server app the code reads the
Int32 and then it knows how many bytes it must read to acquire the entire
serialized IMessage. Then it reads the bytes and deserializes the IMessage.
Of course I've used an OO approach that has grown to be much more complex
but this has been a simplified explanation.
9. Use a RealProxy-derived class on the client-side to communicate with the
server. (The RealProxy can create a __TransparentPr oxy for your server
object on the client machine so that all calls to the server object are
forwarded to your RealProxy where you can submit them across your custom
remoting framework. After a response is received from the server your
RealProxy just returns the IMethodReturnMe ssage implementation and the .NET
framework handles the adaptation of the return message to the actual return
value of the method call. Just override the RealProxy.Invok e method which
encapsulates all of the aforementioned messaging functionality on the
client-side. RealProxy will be impressive if you haven't used it before.
10. As in Remoting your simple framework should close the connection after
each message is sent. (Actually, the Remoting framework seems to buffer
calls or wait after a call for a short period of time so that the connection
is not opened and closed on all invocations.)
11. Just FYI, it's definitely possible, as I've already accomplished in my
framework, to do all of theses steps over a single Socket that remains open
and provides two-way communication. After you get your simple RPC app to
work correctly try to extend it so that it works two-way through a client
firewall using a single Socket. Just a hint, read/write over the Socket
must be synchronized, so using WaitHandles will be useful.
What happens if the network lags, or bytes go missing?
If you are using TCP then you must expect that bytes won't be lost unless
the network fails, in which case the Socket will throw a SocketException .
There is not much you can do to code against faulty hardware or loss of
connectivity other than to try again when you catch a SocketError code that
is not fatal.

HTH

"Shak" <me@privacy.net > wrote in message
news:4f******** *****@individua l.net... Hi all,

Three questions really:

1) The async call to the networkstream's endread() (or even endxxx() in
general) blocks. Async calls are made on the threadpool - aren't we
advised
not to cause these to block?

2) You can connect together a binaryreader to a networkstream:

BinaryReader reader = new BinaryReader(st ream);

And then read an int from it:

int i = reader.ReadInt3 2();

And vice versa.

Since there are no calls to beginread/endread, I presume this isn't a
synchronous call. Is there any way to make it async? Or am I missing the
point?

3) I'm trying to implement the message mechanism described here:

http://msdn.microsoft.com/library/de...rp09182003.asp

In order to answer question 2), I'm going to read the the messagetype
asynchronously, but the rest of the message synchrounously in the callback
(by tying together the binaryreader and networkstream). Is it a good idea
to
do mix the two like this? What happens if the network lags, or bytes go
missing?

Thanks!

Shak


Jun 19 '06 #2
Thanks for the comprehensive reply, Dave! I have a few more questions,
inline:

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..
Hi Shak,

I've submitted some answers to your questions in-line
1) The async call to the networkstream's endread() (or even endxxx() in
general) blocks. Async calls are made on the threadpool - aren't we
advised
not to cause these to block?
If you are worried about blocking a ThreadPool thread then spawn your own
Thread and use synchronous NetworkStream calls.
But I wouldn't worry about it anyway. Just don't call EndRead while on a
ThreadPool thread because nested ThreadPool calling may cause a deadlock.
i.e. don't execute asynchronously on a ThreadPool thread to make another
asynchronous call on another ThreadPool thread (this may cause a
dead-lock).


Do you mean NOT to use the Async callback to reestablish the async? At the
moment I'm doing something like this:

//somewhere else
o.BeginAsync(co mpleteAsync, o)
....

void completeAsync(I AsyncResult ar)
{
Class o = (Class)ar.SyncS tate;
o.EndAsync();
//do stuff for this async cycle
//resestablish wait
o.BeginAsync(co mpleteAsync, o)
}

Which I thought was the established model for eg async reading and writing.
Your point 3 in the RPC method below suggests I should loop with a
synchronous method instead of calling BeginAsync again.
2) You can connect together a binaryreader to a networkstream:

...
Since there are no calls to [BinaryReader's] beginread/endread, I presume
this [is] a
synchronous call. Is there any way to make it async? Or am I missing the
point?


BinaryReader works synchronously. If it's used in an asynchronous
callback then it's being used asynchronously within the context of your
application. In other words, Async callback --> Sync ReadInt32() means
that the ReadInt32() call is now asynchronously executing on a ThreadPool
thread.

If my explanation doesn't work for you than please tell me what is the
architecture you are trying to achieve?


No, that's fine. What I wanted to do was to create a BinaryReader around a
NetworkStream and then call ReadInt32() and then go away, whether there is
an int to be read or not, and get notified when it would be. The solution
I've come to is to use a networkstream's BeginRead to do the wait and then
wrap a BinaryReader around the same networkstream within the callback, since
I now expect there to be data - pretty much how you describe above. I was
just afraid of blocking the the threadpool callback with ReadInt32, but it's
beginning to seem that some kind of blocking is inevitable anyway!
3) I'm going to read the the messagetype
asynchronously, but the rest of the message synchrounously in the
callback
(by tying together the binaryreader and networkstream). Is it a good idea
to do mix the two like this?


I recommend the following approach for a very simple RPC app:


I appreciate that but I think that's a bit too advanced for now! I will look
to use the various concepts in there eventually so it is useful.
What happens if the network lags, or bytes go missing?


If you are using TCP then you must expect that bytes won't be lost unless
the network fails, in which case the Socket will throw a SocketException .
There is not much you can do to code against faulty hardware or loss of
connectivity other than to try again when you catch a SocketError code
that is not fatal.

HTH


OK. I do have another question though: What happens if, while reading bytes
off of a network stream more data gets sent? Abstracting away from the
above, say you are expecting a particular message of unknown length. How do
you know when to stop reading bytes? All the examples I've seen seem to wait
till the number of bytes read<=0. Couldn't we get more than one message
accedentally in that scenario? If at all it stops?

Shak
Jun 19 '06 #3
Hi Shak,

Inline:
If you are worried about blocking a ThreadPool thread then spawn your own
Thread and use synchronous NetworkStream calls.
But I wouldn't worry about it anyway. Just don't call EndRead while on a
ThreadPool thread because nested ThreadPool calling may cause a deadlock.
i.e. don't execute asynchronously on a ThreadPool thread to make another
asynchronous call on another ThreadPool thread (this may cause a
dead-lock).
Do you mean NOT to use the Async callback to reestablish the async?


Actually, I should have written "don't call Begin*" while on a ThreadPool
Thread since it is the Begin* methods that spawn a ThreadPool Thread, not
the End* methods. The reason you shouldn't call into an asynchronous method
from an asynchronous method where both threads will use the ThreadPool is
that it can cause dead-locks because there is a limit to the number of
ThreadPool Threads provided to your application (related to the number of
physical processors). However, for a simple RPC app, especially if there
will be a limited number of client connections, it is acceptable to call
BeginAsync from the AsyncCallback.
Your point 3 in the RPC method below suggests I should loop with a
synchronous method instead of calling BeginAsync again.
If you were to use a synchronous loop you could spawn your own Thread using
a ThreadStart object to prevent dead-locks, but there may be a slight
performance cost. I have not compared the two methods. A problem that you
must work out when using a synchronous loop is that one client should not
have to wait for another client's RPC to complete before it can establish a
connection, so some asynchronous code is still required. Preferably, code
not executing on a ThreadPool Thread.
BinaryReader works synchronously. If it's used in an asynchronous
callback then it's being used asynchronously within the context of your
application. In other words, Async callback --> Sync ReadInt32() means
that the ReadInt32() call is now asynchronously executing on a ThreadPool
thread.


What I wanted to do was to create a BinaryReader around a NetworkStream
and then call ReadInt32() and then go away, whether there is an int to be
read or not, and get notified when it would be. The solution I've come to
is to use a networkstream's BeginRead to do the wait and then wrap a
BinaryReader around the same networkstream within the callback, since I
now expect there to be data - pretty much how you describe above.


The problem I had with using a BinaryReader.Re ad* call to block is that it
doesn't work! The BinaryReader doesn't seem to want to wait. You have to
block, as you said, before using the BinaryReader. I use the
TcpClient.Clien t Socket's Poll method in my framework instead of calling
Stream.ReadByte s.
I was just afraid of blocking the the threadpool callback with ReadInt32,
but it's beginning to seem that some kind of blocking is inevitable
anyway!
Yea, you have to assume that you'll never know how long the delay will be
before a client attempts to connect, and therefore some Thread, somewhere,
must block until it's activated by a client.
I recommend the following approach for a very simple RPC app:


I appreciate that but I think that's a bit too advanced for now! I will
look to use the various concepts in there eventually so it is useful.


NP
If you are using TCP then you must expect that bytes won't be lost unless
the network fails, in which case the Socket will throw a SocketException .
There is not much you can do to code against faulty hardware or loss of
connectivity other than to try again when you catch a SocketError code
that is not fatal.

OK. I do have another question though: What happens if, while reading
bytes off of a network stream more data gets sent? Abstracting away from
the above, say you are expecting a particular message of unknown length.
How do you know when to stop reading bytes? All the examples I've seen
seem to wait till the number of bytes read<=0. Couldn't we get more than
one message accedentally in that scenario? If at all it stops?


A few things here...

1. Only one client will use a any given socket at one time. Therefore, all
asynchronous calls received by the server on a Socket will originate from
the same object instance on the client.
2. If more than one message is sent to the server asynchronously there must
be a mechanism to buffer the messages on the client-side so they are not
mixed together. In TCP you can't sign each packet. The best way around
this in a simple RPC app is to only allow synchronous calls to be made by
the client, enforced on the client, or else you'll have to create a buffer.
3. Many examples and protocols expect the Socket to be closed when the call
is complete. In other words, the client sends a message and closes the
Socket, and the server reads until NetworkStream.R ead() returns 0,
indicating that the Socket has been closed and reading is complete. Not a
very robust solution. Your app would have to open and close a Socket on
every call to the server, and the server would have no way of responding to
the client. Some protocols have an end-of-message mark that is sent after
the entire message. This works for simple, text-only protocols where the
range of input is limited and controlled.
4. In my original post I mentioned that my framework sends an Int32 that
describes the incoming message length before the client-side code serializes
each message. This way the server expects exactly 4 bytes describing the
length of the remaining message and 2147483647 bytes maximum for the
remaining message size. The socket does not need to be closed in order to
signal to the reader that the end of the message has been reached.
5. The client must always know the length of the message, in my example. If
you are using serialized objects for communication then it's possible to
just serialize the object and take the Stream's length as the length of the
message. Write the length to the NetworkStream as an Int32 and then write
the MemoryStream that contains the serialized message. If you do not know
the length of the message then you must use one of the methods I mentioned
in point 3 above.

Serialization is quite easy. Here's a simple example that I have written
for you that illustrates a client transport mechanism:

using System;
using System.Collecti ons.Generic;
using System.Runtime. Serialization.F ormatters.Binar y;
using System.IO;
using System.Net.Sock ets;

static class NetworkTranspor t
{
public static void SendMessage(Mes sage message, NetworkStream
transportStream )
{
if (message == null)
throw new ArgumentNullExc eption("message ");

// I recommend encapsulating the transportStream
// within a class instead of using a static class
// as in this example
if (transportStrea m == null)
throw new ArgumentNullExc eption("transpo rtStream");

// create the stream that will contain the serialized message
using (MemoryStream serializedMessa geStream = new MemoryStream(10 24))
{
BinaryFormatter formatter = new BinaryFormatter ();

// serialize the message to the stream as binary
formatter.Seria lize(serialized MessageStream, message);

// get the length of the stream as an Int32
int length = (int) serializedMessa geStream.Length ;

// convert the length of the stream to an array of bytes
byte[] lengthInBytes = BitConverter.Ge tBytes(length);

// write the length of the stream to the socket (4 bytes from index 0,
which is 32 bits)
transportStream .Write(lengthIn Bytes, 0, 4);

// write the entire serialized message stream to the socket
transportStream .Write(serializ edMessageStream .ToArray(), 0, length);

// the server must read 4 bytes, convert it to an Int32
// and then read the length of the Int32 from the socket
}
}
}

[Serializable]
class Message
// see System.Runtime. Remoting.Messag ing.IMessage for the framework
interface
{
public readonly Dictionary<stri ng, object> Properties = new
Dictionary<stri ng, object>(8);
}
HTH
Jun 19 '06 #4
"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message
news:Oe******** ******@TK2MSFTN GP04.phx.gbl...
Hi Shak,

Inline:
If you are worried about blocking a ThreadPool thread then spawn your
own Thread and use synchronous NetworkStream calls.
But I wouldn't worry about it anyway. Just don't call EndRead while on
a ThreadPool thread because nested ThreadPool calling may cause a
deadlock. i.e. don't execute asynchronously on a ThreadPool thread to
make another asynchronous call on another ThreadPool thread (this may
cause a dead-lock).
Do you mean NOT to use the Async callback to reestablish the async?


Actually, I should have written "don't call Begin*" while on a ThreadPool
Thread since it is the Begin* methods that spawn a ThreadPool Thread, not
the End* methods. The reason you shouldn't call into an asynchronous
method from an asynchronous method where both threads will use the
ThreadPool is that it can cause dead-locks because there is a limit to the
number of ThreadPool Threads provided to your application (related to the
number of physical processors). However, for a simple RPC app, especially
if there will be a limited number of client connections, it is acceptable
to call BeginAsync from the AsyncCallback.


I think that's how I had read it anyway! I do understand the danger here,
but if the re-call to Begin* is the last thing done in the callback (ie the
callback has no more oppurtunity to block) then wouldn't it be ok, even in
the worst case? I think I'll have no more than a handful of clients anyway,
but I'll think about moving to a loop I ever need to scale it up.
Your point 3 in the RPC method below suggests I should loop with a
synchronous method instead of calling BeginAsync again.


If you were to use a synchronous loop you could spawn your own Thread
using a ThreadStart object to prevent dead-locks, but there may be a
slight performance cost. I have not compared the two methods. A problem
that you must work out when using a synchronous loop is that one client
should not have to wait for another client's RPC to complete before it can
establish a connection, so some asynchronous code is still required.
Preferably, code not executing on a ThreadPool Thread.


Hmm. But if a socket has already been established (and has it's own thread
on which it is reading on), surely it wouldn't matter? Going back to my
Async model:

//somewhere else
o.BeginAsync(co mpleteAsync, o)
....

void completeAsync(I AsyncResult ar)
{
Class o = (Class)ar.SyncS tate;
o.EndAsync();
//do stuff for this async cycle
//resestablish wait
o.BeginAsync(co mpleteAsync, o)
}

This is as opposed to a sync loop:

//somewhere else

StartAThread(o. Work) //(1)
....

void Work()
{
while (true)
{
o.Begin(); // blocks
//do stuff for this cycle.
}
}

Where (1) can be replaced by your thread-kicking-off code of choice.
Presumeably for the TCPClient connecting case, "do stuff for this cycle"
means to establish a further thread to poll on read (either via async or
kicking off another thread manually). I don't think either introduce the
possibility of deadlock, although I'm now seeing the latter as being more
efficient since it doesn't create new threads. Do both these models fulfill
your condition that "one client should not have to wait for another client's
RPC to complete before it can establish a connection", though?

It seems that most Async calls (especially in streams and the like) seem to
be for a job that repeats. If this is the case, and a loop that blocks is
more efficient, what's the point of having Async calls? I mean it's not like
you'll only want to read or write to a stream once, right?
OK. I do have another question though: What happens if, while reading
bytes off of a network stream more data gets sent? Abstracting away from
the above, say you are expecting a particular message of unknown length.
How do you know when to stop reading bytes? All the examples I've seen
seem to wait till the number of bytes read<=0. Couldn't we get more than
one message accedentally in that scenario? If at all it stops?


A few things here...


That's brilliant, and exactly as I imagined it to be. In short, you have to
be able to determine when what you're receiving ends, usually using some
kind of prefix or suffix. Cool!

Shak
Jun 20 '06 #5
Hi Shak,

Inline:
Actually, I should have written "don't call Begin*" while on a ThreadPool
Thread since it is the Begin* methods that spawn a ThreadPool Thread, not
the End* methods. The reason you shouldn't call into an asynchronous
method from an asynchronous method where both threads will use the
ThreadPool is that it can cause dead-locks because there is a limit to
the number of ThreadPool Threads provided to your application (related to
the number of physical processors). However, for a simple RPC app,
especially if there will be a limited number of client connections, it is
acceptable to call BeginAsync from the AsyncCallback.
I think that's how I had read it anyway! I do understand the danger here,
but if the re-call to Begin* is the last thing done in the callback (ie
the callback has no more oppurtunity to block) then wouldn't it be ok,
even in the worst case? I think I'll have no more than a handful of
clients anyway, but I'll think about moving to a loop I ever need to scale
it up.


I see your point that waiting for the call to complete before accepting the
next client should solve the problem of ThreadPool Thread usage and
dead-locking, however the recommendation exists because it may be out of
your control how many other blocks of code will be using a ThreadPool Thread
to call into your library and you can't say for sure that even the .NET
framework code isn't using ThreadPool Threads internally. In other words,
it's not safe to assume that the number of ThreadPool Threads being used by
your application can be managed simply be rearranging the order of async
calls in your code.
If you were to use a synchronous loop you could spawn your own Thread
using a ThreadStart object to prevent dead-locks, but there may be a
slight performance cost. I have not compared the two methods. A problem
that you must work out when using a synchronous loop is that one client
should not have to wait for another client's RPC to complete before it
can establish a connection, so some asynchronous code is still required.
Preferably, code not executing on a ThreadPool Thread.


Hmm. But if a socket has already been established (and has it's own thread
on which it is reading on), surely it wouldn't matter? Going back to my
Async model:


The syncronous model is actually sync/async. Clients are accepted within a
synchronous loop and the code spawns a non-ThreadPool Thread to process the
request. There is no chance for dead-locking due to the physical ThreadPool
quantity, only in explicit synchronization code such as with the use of
Monitor.Lock or WaitHandles.
//somewhere else
o.BeginAsync(co mpleteAsync, o)
...

void completeAsync(I AsyncResult ar)
{
Class o = (Class)ar.SyncS tate;
o.EndAsync();
//do stuff for this async cycle
//resestablish wait
The problem here is that all clients are queued even though your app should
be able to handle more than one request simealtaneously . You should call
o.BeginAsync immediately after o.EndAsync to start listening for another
client request before processing the current request. A problem that would
arise in a scaled-up application may be that too many subsequent requests
from different clients might block the first request from ever completing if
o.BeginAsync steadily completes synchronously. Just FYI.
o.BeginAsync(co mpleteAsync, o)
}

This is as opposed to a sync loop:

//somewhere else

StartAThread(o. Work) //(1)
...

void Work()
{
while (true)
{
o.Begin(); // blocks
//do stuff for this cycle.
}
}

Where (1) can be replaced by your thread-kicking-off code of choice.
Presumeably for the TCPClient connecting case, "do stuff for this cycle"
means to establish a further thread to poll on read (either via async or
kicking off another thread manually). I don't think either introduce the
possibility of deadlock, although I'm now seeing the latter as being more
efficient since it doesn't create new threads. Do both these models
fulfill your condition that "one client should not have to wait for
another client's RPC to complete before it can establish a connection",
though?
Well, your example is not exactly the complete story for the sync/async
client-acceptance model.

// Here's a quick example that I wouldn't use in a real app as-is. Try an
OO approach instead.
// NOTE: this code was not tested and may not build
class Server : System.Componen tModel.Componen t
{
private readonly TcpListener listener = new TcpListener();
private bool running;

public void Start()
{
running = true;

// start listening for client connections
Thread listeningThread = Thread(new ThreadStart(Lis tenAsync));
listeningThread .Start();
}

private void ListenAsync()
{
while (running)
{
// block until a client connects
// TODO: handle exception if listener is disposed in a different
Thread; fail silently
TcpClient client = listener.Accept TcpClient();

if (!running)
// if, while blocking, a different Thread changed the 'running'
state of the class but did not dispose of the listener
{
DisconnectClien t(client);
break;
}

// As soon as the client is connected spawn another thread to
handle the request.
// This way, another connection will not be blocked until the
current request has been handled.
// Even if you were to call listener.BeginA cceptTcpClient here
the current request would
// still have to complete before the next connection would be
accepted, like the "queue"
// I mentioned above, since you wouldn't be listening for
another client until the end of the method.
Thread requestHandler = Thread(new
ParameterizedTh readStart(Handl eRequestInterna l))
requestHandler. Start(client);

/*
ASP.NET, I believe, uses a custom ThreadPool to do exactly what
I've done here,
which has either a manageable limit to the number of concurrent
requests or no limit.
Spawning a new Thread for each request might be too costly for
some applications
if they are not pooled.
*/
}
}

private void HandleRequestIn ternal(object info)
{
using (TcpClient client = (TcpClient) info)
{
// TODO: prepare request

try
{
HandleRequest(c lient);
}
finally
{
DisconnectClien t(client);
}
}
}

private void HandleRequest(T cpClient client)
{
// TODO: handle request
}

private void DisconnectClien t(TcpClient client)
{
client.GetStrea m().Close();
client.Dispose( );
}
}
It seems that most Async calls (especially in streams and the like) seem
to be for a job that repeats. If this is the case, and a loop that blocks
is more efficient, what's the point of having Async calls? I mean it's not
like you'll only want to read or write to a stream once, right?


It may not be that a blocking loop is more effecient. Actually, as I've
mentioned, it might be less effecient unless properly coded. The reason for
using a loop is that it illeviates ThreadPool usage where it might be
problematic. The ThreadPool is very useful to queue up a task that must be
processed in the background (i.e. BackgroundWorke r should be used in .NET
2.0) to free up a GUI Thread so that the end user has a better experience
with your application, and it can handle multiple tasks that may start and
stop frequently very efficiently, however it's not useful for servicing an
unlimited number of requests from remote clients or for code that blocks
during the lifetime of the application.
OK. I do have another question though: What happens if, while reading
bytes off of a network stream more data gets sent? Abstracting away from
the above, say you are expecting a particular message of unknown length.
How do you know when to stop reading bytes? All the examples I've seen
seem to wait till the number of bytes read<=0. Couldn't we get more than
one message accedentally in that scenario? If at all it stops?


A few things here...


That's brilliant, and exactly as I imagined it to be. In short, you have
to be able to determine when what you're receiving ends, usually using
some kind of prefix or suffix. Cool!


You got it. I don't know how many other ways there are for doing this but
I've had a lot of success with the "suffix" approach.

HTH
Jun 20 '06 #6
"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message
news:eg******** *****@TK2MSFTNG P03.phx.gbl...
//somewhere else
o.BeginAsync(co mpleteAsync, o)
...

void completeAsync(I AsyncResult ar)
{
Class o = (Class)ar.SyncS tate;
o.EndAsync();
//do stuff for this async cycle
//resestablish wait
The problem here is that all clients are queued even though your app
should be able to handle more than one request simealtaneously . You
should call o.BeginAsync immediately after o.EndAsync to start listening
for another client request before processing the current request. A
problem that would arise in a scaled-up application may be that too many
subsequent requests from different clients might block the first request
from ever completing if o.BeginAsync steadily completes synchronously.
Just FYI.


.... Because callbacks run on threadpool threads, and so you can only have x
number of calls to BeginAsync that haven't yet completed their callbacks?

Well, your example is not exactly the complete story for the sync/async
client-acceptance model.

// Here's a quick example that I wouldn't use in a real app as-is. Try an
OO approach instead.


That seems to be the model mine has evolved to, so thanks.
It seems that most Async calls (especially in streams and the like) seem
to be for a job that repeats. If this is the case, and a loop that blocks
is more efficient, what's the point of having Async calls? I mean it's
not like you'll only want to read or write to a stream once, right?


It may not be that a blocking loop is more effecient. Actually, as I've
mentioned, it might be less effecient unless properly coded. The reason
for using a loop is that it illeviates ThreadPool usage where it might be
problematic. The ThreadPool is very useful to queue up a task that must
be processed in the background (i.e. BackgroundWorke r should be used in
.NET 2.0) to free up a GUI Thread so that the end user has a better
experience with your application, and it can handle multiple tasks that
may start and stop frequently very efficiently, however it's not useful
for servicing an unlimited number of requests from remote clients or for
code that blocks during the lifetime of the application.


In other words, if you need to do it more than once and at arbitrary times,
think about moving an async call to its own thread.

Thanks for all the help...

Shak
Jun 20 '06 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
2007
by: Dave | last post by:
I'm using the BeginInvoke method of a delegate to invoke a thread asynchronously and then use the EndInvoke to retrieve the value. This works wonderfully until a Serviced Component is added to the mix. When the Serviced Component is invoked with BeginInvoke, the code hangs for the duration of the call rather than running async. Any ideas? Sample code below: Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As...
0
1038
by: Mark | last post by:
Hi all, i am trying to create a small app which can record the requests from and responses to my browser. To achieve this i am using two tcpclients and a listener. The first 1 is listening to a port on my localhost to intercept the browsers request. The second 1 uses the stream of tcpclient1 and forwards it to the target. The response-stream from the target is read from tcpclient2 and
6
10464
by: Vanessa | last post by:
I have a question regarding async mode for calling Microsoft.XMLHTTP object. Microsoft.XMLHTTP hangs the IE once in a while suddenly, but it will work again after half an hour or so without doing anything. I have searched through the Internet and seems like the reason it hangs the browser it's because XMLHTTP limits you to two concurrent HTTP connections to each remote host; so if more than 2 concurrent connections strike the script...
0
1847
by: Passynkov, Vadim | last post by:
I am using Asynchronous Query Processing interface from libpq library. And I got some strange results on Solaris My test select query is 'SELECT * from pg_user;' and I use select system synchronous I/O multiplexer in 'C' The first test sends 10000 select queries using 10 nonblocking connections to database ( PQsendQuery ). The second test sends the same 10000 select queries using 1 connection ( PQexec ).
10
2973
by: Shawn Meyer | last post by:
Hello - I am trying to write a class that has an async BeginX and EndX, plus the regular X syncronous method. Delegates seemed like the way to go, however, I still am having problems getting exactly what I want. Here are my goals 1. I would like the IAsyncResult that is returned by the Begin function to be able to be waited on or polled to check for completion. 2. The Begin function would take a callback, and the async process would
8
5897
by: TS | last post by:
Im in a web page and call an asynchronous method in business class. the call back method is in the web page. When page processes, it runs thru code begins invoking the method then the page unloads. When the callback method is raised, only the method in the web page is run and the page never refreshes, it seems it all happens on the server side. I am trying to refresh the constrols on the page inside the callback method, but when id...
1
1002
by: Jerry Spence1 | last post by:
I am currently looking at writing a TCP client for talking to a number of networked card readers. With Vb.Net, the process hangs pending an input. To overcome this problem I am using the ThreadPool class and spawning a thread for the TCPClient to wait for an input, which I then process. However I want to design the software to cope with a large number of readers (say 100). Is there any problem with me creating 100 threads and 100...
1
4329
by: Simon Hart | last post by:
Hi, I thought I'd just open a thread in an attempt to get peoples feelers with regards to multithreading vs Async Web Service processing. Of course Web Services makes it easy to do Async method calling, but what if you are already in a worker thread in a Windows Forms application when doing the web service call. In this case there is no need to use Async Begin..End features that .NET kindly presents us with.
10
4520
by: Frankie | last post by:
It appears that System.Random would provide an acceptable means through which to generate a unique value used to identify multiple/concurrent asynchronous tasks. The usage of the value under consideration here is that it is supplied to the AsyncOperationManager.CreateOperation(userSuppliedState) method... with userSuppliedState being, more or less, a taskId. In this case, the userSuppliedState {really taskId} is of the object type,...
0
9876
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
10948
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10617
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10677
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10318
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9457
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7862
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
2
4094
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3147
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

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.