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. > > > > > > > > > > > >
