Fastest way to transfer Data over tcp

[Qiieha]

Hi,
Maybe you can help me...

What is the fastest way to transmit Objects of classes over Tcp. I know Xml and I can comprime it,

f.e:


<Map>
<Entry>
<Key>45</Key>
<Value>
<Object>
<Member1>...</Member1>
<Member2>...</Member2>
...
</Object>
</Value>
</Entry>
etc. ....


but is it the fastes way?

thank u ; )

[wysota]

Define what you mean by "fastest".

[Qiieha]

I mean speedy...

[wysota]

In terms of writing code, data transfer or what else?

[Qiieha]

sorry, I mean data transfer...

[wysota]

The fastest way is to develop your own binary protocol that will only transfer information that is really required, making use of some implicit domain knowledge like default values of fields in particular objects.

By the way, next time please post such questions on "General Programming" forum.

[Qiieha]

Should I use the Hessian Protocol?

[wysota]

You can use any protocol you want. But like I said, if you want "fastest" then you need your own protocol.

[Qiieha]

so there is a simple protocol



size //the socket knows, if all data is here
whatfor //command
data //the map f.e


Can u show me a common protocol for a QMap<QString,QString>, please.

[wysota]

No, I can't. You need to develop it on your own considering your particular application needs. It's not something you can do in two minutes.

[Qiieha]

I never worked with binary protocols...

[wysota]

So forget about having the "fastest way" and focus on what you can do.

[Qiieha]

Do you know a website with a good explanation or a tutorial?
I want to know how to encode and decode such messages. QDataStream is not needed, isn't it?

[wysota]

Do you know a website with a good explanation or a tutorial?
I doubt there is a tutorial on designing a binary protocol for your application. Even if there was, it would not help you much. I suggest you leave this topic and focus on what you understand (e.g. using XML as the carrier).

[Qiieha]

But performance is very important in my case.
Do you mean that compressed xml suffices, with its serialisation and deserialisation?

What is with basic Object Serialisation in QDataStream?

[wysota]

With XML you still have to decide what to transmit and how. Whatever works, is sufficient. But it doesn't have to be optimal or even close to being optimal.

[Qiieha]

But I want to know how to do it with my own protocol. :p

[wysota]

But I want to know how to do it with my own protocol. :p

Then sign up for a course on protocol design.

[Qiieha]

Then sign up for a course on protocol design.

What's with this link [URL="https://developers.google.com/protocol-buffers/docs/overview?hl=de-DE"]?

[Destiser]

But I want to know how to do it with my own protocol. :p

Actually, building your own protocol isn't that hard if you can keep it simple. You just need to know what you must send/receive. When talking about fixed data frames (by that I mean that you know what type of data is comming, the count isn't important because you can specify that in a sizefield of your protocol).

Think of following super-simpel protocol:

Size (WORD or uint16) = number of bytes following
Data

If you know that "Data" is an array of say foo, and you know that foo contains 2 32bit integers en a double (64bits), than you need to send only 128bits or 16bytes data per foo class, if you want to send 3 foo's, you need to send 48bytes of data, the Size-field is 48, so you know how many bytes the dataframe is. Store the bytes in a byte-array. Because you know the size of your dataframe and you know the size of your foo , you can calculate that you received 3 foo's. From there on you can extract the data from te byte-array and create 3 foo's on the receiver.

If you must send diffrent types of data, you can specify a 'Command'-field (wich is 1 byte for instance) that specify the type of data that is in the Data-field.

If you need to send a mixture of undefined data (I mean, you wanna send ones 3 times foo, 4 times faa and 1 fuu; but the next time it can be 12 fuu and 1 faa) than things get complicated. But, try to figure out first if you can do it in a simple manner.

Hope this quickie helped

[wysota]

Think of following super-simpel protocol:

"super-simple" is rarely optimal.

[Destiser]

"super-simple" is rarely optimal.

I would say it is optimal in super-simple cases :)

But, the topic starter should indeed mention what he wants to send over tcp, what is the goal of the message? It can make things clear.