TCPClient Synchronous or Asynchronous Writes

[Guest]

First, my question: Should I use Write or BeginWrite (sync or async) to
stream data to my clients over a TCPClient connection.

Details:
On the server I have a custom circular data buffer that receives byte array
data representing data structures at a rate of 30ms.

On a thread seperate from that which Enqueues data to the buffer I have a
high performance timer that Dequeues data from the custom buffer and sends it
via a tcpClient connection to the client. The Dequeue timer runs at a rate
greater than or equal to the Enqueue rate so the buffer never fills up.

On the Client I have a similar custom data buffer that will buffer the data
it receives from the server until it can be displayed.

My data needs to be displayed in the order it was originally created.

I have googled the internet for hours but I am still not sure if I should be
sending my data to the client using Write or BeginWrite/EndWrite. I know
that with Write I am gauranteed the proper order, which is good, but will
Write be able to keep up performance wise? Or should I use
BeginWrite/EndWrite, then have logic on the client to make sure things are in
the correct order.

Any insight into this is very appreciated!

 

[Dan Bass]

Generally, if order is that important you should stick with synchronous. If
you go the asynchronous route, there's no guarantee the first packet of data
will arrive before the second... In my thinking you'd only use the
multithreading option if sending to multiple clients.

Hitting TCP this often and hard wouldn't be desirable for any network.
Because the rate is so high, is there an option of buffer up your data and
post it off to the client every few seconds in one block. The client would
then separate the data into sub-blocks it needs again. There'd also be
facility here then to handle things like dropped connections, where the data
that is ready to send gets buffered up until the connection is
re-established.

Out of curiosity, what the scenario surrounding these few stages? Perhaps
there are other ways of doing what you are trying to accomplish.

Good luck.
Dan.

 

[Guest]

Dan, thanks for the response.

Here are the details of my situation.

There are 5 computers sitting around a manufacturing machine. The computers
are connected by a fairly high speed closed network. One of the 5 computers
acting as the "server" receives quality assurance data from different
measurement devices situated around the machine. The max rate that the
machine can send this measurement data to the server is ~30ms. The data
comes into the Server as byte arrays representing various data structures.

The goal is to get this data out to each of the 4 clients so that it can be
displayed graphically to the machine operators. The data has to arrive as
close to real time as possible (it can lag a little) and it has to be in
order.

Currently, as the data comes into the server it is immediatly Enqueued into
a Circular Buffer. Each client can register to look at differnt data so there
is actually a Circular Buffer for each client. A seperate thread running on
a high performance timer constantly pulls (Dequeues) items from the Buffers
and sends them (via tcp/ip) to each client.

Once the client receives a data item, it throws that item into a client side
Circular Buffer. Another thread on the client, again running on a timer,
pulls items from this buffer and displays the data.

FYI, each data structure is ~200-300 bytes.

I'd be interested in hearing other solutions. For now, I think I will look
into possible sending items from client to server in groups rather than one
at a time. Is it your opinion this would improve my performance, since my
send rate would be lower. (even though the size of the data being sent would
be larger.)

 

[Dan Bass]

I'd be interested in hearing other solutions. For now, I think I will

look
into possible sending items from client to server in groups rather than
one
at a time. Is it your opinion this would improve my performance, since my
send rate would be lower. (even though the size of the data being sent
would
be larger.)

That mainly depends on what you're doing with the connections.

If you create a connection each time, then send the data down to the client,
then close the connection, then buffering it up and posting it every 2
seconds say, would be more efficient from the point of view that the
overhead to create and close a connection would be greatly reduced on the
server.

If you're trying to maintain an open connection to a client, then sending it
as you receieve it wouldn't appear to have much impact. You should then
cater for the case where the connection can't be made... From what you're
saying you can't really loose any data, in which case the data should get
buffer until a connection can be established. For each client,
synchronousity would be essential. This would appear to be a more
"real-time" solution.

Good luck.

 

[Guest]

When an operator navigates to a particular screen on the client, a tcpClient
connection is established with the server. This connection is held open
until the operator navigates away from the form.

I can't loose data for a particular operator viewing data on a particular
form, but I don't have to capture all the data all the time. I only have to
buffer the data that the operators have currently chosen to view.

If a connection is lost while they are viewing this data than that is really
outside the scope of my application and would fall to the internal networking
guys to fix. On loss of a connection, the buffer would just fill up to fast
for me to try and wait for a connection to be re-established.

Thank you for your help!

 

[Dan Bass]

In this scenario it would be best to keep it simple.
There's a listener presumably on the server, which fires an event for each
connection attempt a client makes on it.
This event would create a client object which contains a connection to the
client. The client would then be used to published events to which the
client is subscribed. This would be done on a synchronous basis for two main
reasons. The first is readbility, it so much easier to track events through
when you see where the control is going, and what each method is doing. The
second is order appears to matter in terms of when the data is read and
posted from the server, to the order in which it is received by the client.

You need to handle cases where:
- the connection with the client is working fine
- the client closes the connection
- the connection drops off (network failure), the client should re-establish
the connetion with the server and the old client connection object should
probably be removed from the live client list

This is a common instance of "publish subscribe" architecture.

Hope it goes well for you.