[zeromq-dev] protocol design question

[Min RK]

On Nov 15, 2011, at 12:45, Chuck Remes <cremes.devlist at mac.com> wrote:

> 
> On Nov 15, 2011, at 2:36 PM, MinRK wrote:
> 
>> e.g.
>> 
>> struct sequence_id {
>>  uint64 number;
>>  uchar  uuid[16];
>> };
>> 
>> Is this all right? Or is there a better way to accomplish this framing?
>> 
>> cr
>> 
>> I have a general question related to this - what is the relative cost in zeromq of these being separate very-small messages versus one packed message? Has someone done perf tests for this kind of thing?
> 
> I haven't tested it, but I assume that reading a multipart message versus a single-part message is more time consuming due to 2 factors.
> 
> 1. The I/O thread needs to make sure all parts are accounted for before atomic delivery.
> 
> 2. The #recv has to examine the message frame for the RCVMORE bit.
> 
> It's minor work, but as we all know, the fastest code is "no code."
> 
> On a related topic, I packed these two details together because they are logically related. The unique sequence_id is a combination of sequence_number and uuid.

Right - I don't doubt that it's faster in this case, I was just wondering what the general cost might be, noting that this is presumably always part of a multipart message, so what is the cost of one extra msg part vs two, on top of the real content of the message.

For instance, let's say I had two small strings to send that are *not* already packed together in a struct, under what conditions is it preferable to pack them into one message, and when is it better to leave them as separate?

MinRK

> 
> cr
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111115/e35c10b4/attachment.htm