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