Raw structs as network packets (was: Re: svn commit: samba r20943
- in branches/SAMBA_4_0/source/cluster/ctdb/common: .)
abartlet at samba.org
Mon Jan 22 03:50:00 GMT 2007
On Mon, 2007-01-22 at 03:33 +0000, tridge at samba.org wrote:
> Author: tridge
> Date: 2007-01-22 03:33:12 +0000 (Mon, 22 Jan 2007)
> New Revision: 20943
> WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba&rev=20943
> use offsetof() instead of sizeof() - 1 for the packet length
> calculations. It will be interesting to see how portable this is.
> The advantage over the sizeof() method is that it avoids padding
> problems after the data array. That was causing us to get valgrind
I know this is a speed hack protocol, but I still think that blasting
raw localhost-endian memory onto the network as a 'network packet' is
incredibly poor protocol design.
Has the overhead of using our NDR engine been measured? Or at the very
least, can we have all the packets with a fixed endianness, a magic
identifier and a version number? Byteswapping is a single instruction
on many chips...
At linux.conf.au, you were discussing the need for a wireshark decoder
for this protocol. How should this handle guessing the protocol,
without any clue as to host endian?
Talking with the SGI folks, they are worried that long term, when real
customers deploy this, they will mix architectures, and even program
versions. Even if we don't support this (and I think we should at least
try to, for sane combinations), we should at least ensure the protocol
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20070122/ba69166d/attachment.bin
More information about the samba-technical