Hi Anton, I hadn't been following your previous posts close enough to realise you wanted to use a binary format. My comment to use ASCII (0-9) was meant instead of a HEX type format (0-F).
Binary would work for me too, but you MUST pad it out to the byte boundary. It is nightmare to code otherwise. BER is very efficient, but yuck to code against. I vote for simplicity over efficiency in this case. Cheers Andrew -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anton Okmianski Sent: Thursday, 22 April 2004 3:14 a.m. To: [EMAIL PROTECTED]; 'Rainer Gerhards' Cc: [EMAIL PROTECTED] Subject: RE: Message size limit Andrew, Rainer & all: Why ASCII? I was planning on using binary for transport specification. Encoding even a length of 1024 with space takes 5 octets in ASCII. In binary, I dedicate 4 bytes to length, which can cover up to 4bln. Note: this does not mean that -protocol should allow that much. Here is a transport packet format I am working on: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Message Identifier (3 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Offset (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Message (variable length) +-+-+-+-+-+ . | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The first bit in Flags indicates if this is a multi-part message. Second - if there is more fragments. For single-part messages, there is two options: (a) use the same header and declare certain fields insignificant or (b) use a different header which only contains Flags field. I am not yet clear which approach is better. I am checking precedents. The other issue is that message Length is redundant in all but the first packet of a multi-part message. This is because length of each segment can be inferred from the length of the datagram which is in the IP/UDP headers. We only need Length field to indicate total message length of a fragmented message in the first datagram. Also, I am not sure about the Padding. Seems like many protocols try to make packet fields align to 32-bit boundaries. I am not sure why this is necessary - I will explore. Any comments? Thanks, Anton. > -----Original Message----- > From: Andrew Ross [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 21, 2004 9:39 AM > To: 'Rainer Gerhards'; 'Anton Okmianski' > Cc: [EMAIL PROTECTED] > Subject: RE: Message size limit > > > > I'd agree with Rainer that ASCII digits for length would be > best. This would be more in line with the way numbers are > represented in BEEP exchanges. 16MB is a LOT of message. If > anyone wants to send more, point them to the FTP RFC :-) > > Cheers > > Andrew > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Wednesday, 21 April 2004 9:13 p.m. > To: Anton Okmianski > Cc: [EMAIL PROTECTED] > Subject: RE: Message size limit > > > Anton: > > I advocated for no limit, but I sea the reasoning ;) I'd go > for 24 bits, that should be more than far enough for not only > the forseeable future. One may argue this is to much, but > this has been argued so often in the past... and prooved to > be wrong. So I'd like to waste some more bandwidth. I suggest > that you use variable-length fields for your header (ASCII > digits terminated by SP) as seldomly someone will need these > big numbers. > > Regarding the minimum, I also agree. I think it should be 512 > (as in DNS). We should just ensure that - if your header is > added - it still fits into the minimum MTU (which is 576 out > of my head... but I may be wrong here). > > I also suggest that -protocol should say. > > "Messages SHOULD be less than 1024 bytes, but MAY be as large > as 16777000 bytes". I have reduced the 24 bit max by 215 > bytes to take care for your header. > > I think pointing out that a the max message size should be > less than 1K could probably save us from too many > "large-message-implementations". I'd like to have people > think about what they do. But maybe doing it in the normative > part is not a good idea... > > Comments on this suggestion? > > Rainer > > > -----Original Message----- > > From: Anton Okmianski [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 21, 2004 12:53 AM > > To: Rainer Gerhards > > Cc: [EMAIL PROTECTED] > > Subject: RE: Message size limit > > > > Rainer: > > > > Are you going to specify a message size limit in -protocol? > > > > I think we do need some limit. For fragmentation in > -protocol I need > > to know how many bytes to dedicate to the fragment offset and > > potentially message length. > > > > I suggest we limit it to 4GB in size (32 bit size) or 16MB (24 bit > > size). We can also recommend that implementations of > receivers provide > > a configuration option for a maximum accepted message size. > Keeping > > even a single 4GB message in memory becomes quite a > challenge. I think > > we should also specify a minimum message size that all syslog > > receivers MUST support in any configuration. This will be > kind of like > > the minimum MTU that hosts on the internet must support. > > > > Thanks, > > Anton. > > > > > > > > > > > >
