views:

159

answers:

4

i have lots of data like this 1:0x00a4c7d9fb3849...
2:0x79821309bd789c7689c97...
3:0x0178dce67fe898...

they are more than 100 per second and speed is the most important thing(network is always busy).

what should i use to transfer my data(tcp/ip, pipes, via, etc)?
how should i serialize it(BinaryFormatter,Xml,User defined or any better advices)?

+1  A: 

If you're sending lots of data, and if the data isn't critical, then UDP is the best option. However, this will potentially lose packets (you may lose one of your datasets across the wire). This is often fine, if your data is doing something like updating a real-time chart, since a missing value doesn't really matter.

If, however, missing data is critical, then TCP/IP will be your best option for sending data across the network. Given the high rate of data, you'll be best off making your own user-defined binary format, and just sending/receiving raw bytes. Using Xml will be much, much chattier (which means more overhead). Even BinaryFormatter will add some overhead, since the serialization tends to add a bit more than absolutely necessary.

Reed Copsey
do you know some good way for user defined serialization?i can use a struct to send data but data length is variable and i can`t identify them.
Behrooz
Usually, for a simple string, the easiest option is to send a string length (bytes) as an int, then the string as bytes. Repeat as necessary. This kind of requires TCP, though, since you need to make sure you get correct ordering of packets.
Reed Copsey
thanks. that should work.
Behrooz
A: 

100 per second of these strings doesn't look like too much of an issue (or the strings must be very long).

binary is always much more condensed than it's string representative. You could potentially even pack it first(using zip or anything else)

TCP/IP would be a good bet if you want full control over sending.

Toad
they are at least 10KBytes long and there are at least 30 clients.
Behrooz
A: 

This looks like binary data (e.g. data which can be packed into byte[] instead of using strings). For best efficiency, you can design your own protocol on top of TCP/IP (using TCP, or even UDP), and maybe even compress the data on the fly, if network load is a big issue. Make sure that you don't send many small chunks, but rather send larger (e.g. 1400 bytes may be a good size) blocks across the network.

Lucero
A: 

100 a second might not be as bad as you think.

If each of those are 100 bytes (100 digits should fit in that, no problem), 100x100 is 10000 bytes a second, or 10Kbps.

I'd use whatever I was most familiar with, and worry about speed if the first solution didn't work. The ideas you get building that first solution will/would make a second solution much easier to build, and you'll get to the final product faster or at the same time you would have, except with less frustration.

Dean J