views:

164

answers:

3

Let's say I have a simple tcp server generating an array inside a thread, serializes it and sends it to a client over tcp connection and when it reaches the client, the client deserializes it and performs something...ie. continuous calculation. Well it's a pretty straight forward process but I would like to know if the process has any performance tradeoff? For example would the client get to do something as fast as the thread produces the arrays, I mean for example, if the thread produces 100 arrays in a second (100 m/s), would the client get 100 arrays in a second too? can the object be serialized and deserialized at real-time? would be pleased if anyone can explain this to me.

well of course ignore the unreliable tcp performance.

Thanks!!

A: 

By real time, do you mean to say "simultaneously" ? If yes, then keep sending the array members as you produce them. But that will help only if the time taken to cal. each array element is considerable.

If you don't mean to say, simultaneously, IMHO, that shouldn't be much of a time delay in serializing/deserializing.

Amit
not simultaneously, real-time for example 100 arrays to serialize and deserialize for every second for both server and client. not interested in the time taken for the 'pack of 100 arrays' to reach the client though.
Faiz
A: 

Real time is probably not the right term to use here unless you are talking about hard deadlines, which i see in this scenario is not really possible , cause we are talking about 3 in between steps .. serialize , send over network and unserialize.

There is no real way to predict accurately what will happen. If we take the network delay out, the rest really depends on how fast the receiving machine is. If its busy or has a lower power than the sending machine, it might not process as much as the sender machine sent.

Also the real question here is the cost of serializing and unserializing in terms of CPU time.. from what i understand , unserializing is a more costly operation. So my guess is receiver will have a hard time keeping up, so you might want to send back an ack before you send another package.

Sabeen Malik
A: 

In this scenario, the serialisation cost is effectively added to the time taken for the server to generate the array, and the unserialisation cost is added to the time taken for the client to process the array.

If:

  • TG is the time used by the server to generate one array;
  • TS is the time taken to serialise one array;
  • TU is the time taken to unserialise one array; and
  • TP is the time used by the client to process one array.

(All times in seconds)

Then if TP + TU < TG + TS, the process will be limited by the server speed and you will be able to process up to 1 / (TG + TS) arrays per second. If that's greater than 100, then you can meet your target.

On the other hand, if TP + TU > TG + TS, then the process will be limited by the client speed, and you will be able to process up to 1 / (TP + TU) arrays per second.

caf