Hi All,
This sounds good and I believe that we have had a reasonable discussion of
all of the options. Unless there are strong objections, I'll ask Fuyou
and Yuzhi to incorporate this into their document.
Thanks,
Chris
On Sat, 18 Mar 2006, Balazs Scheidler wrote:
On Fri, 2006-03-17 at 17:
On Fri, 2006-03-17 at 17:43 +0100, Rainer Gerhards wrote:
> Chris,
>
> while I think this sounds very tempting, I also think there are some
> inherent problems with it:
>
> #1 you do not know *where* (more precise: after how many octets) that
> element is present
> In extreme cases, it might only
> Cc: [EMAIL PROTECTED]
> Subject: RE: Framing in syslog messages -
> RE:[Syslog]Preliminarysyslog-transport-tls document - issue 3
>
> Bazsi,
>
> > Agreed, let's go for octet-counting. How would that look like? Two
> > octets before every message? That would
ly?
Anton.
> -Original Message-
> From: Balazs Scheidler [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 17, 2006 10:15 AM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: RE: Framing in syslog messages - RE:
> [Syslog]Preliminarysyslog-transport-tls document - issue 3
&g
ct: RE: Framing in syslog messages - RE:
> [Syslog]Preliminarysyslog-transport-tls document - issue 3
>
> Hi,
>
> Why wouldn't this information be contained in a structured
> data element
> within each frame?
>
> Thanks,
> Chris
>
> On Fri, 17 Mar 2006,
Hi,
Why wouldn't this information be contained in a structured data element
within each frame?
Thanks,
Chris
On Fri, 17 Mar 2006, Rainer Gerhards wrote:
Bazsi,
Agreed, let's go for octet-counting. How would that look like? Two
octets before every message? That would limit message size to
Bazsi,
> Agreed, let's go for octet-counting. How would that look like? Two
> octets before every message? That would limit message size to 64k, is
> that sufficient? (I personally say it is, messages larger
> than 64k would
> potentially mean that they cannot be held in memory)
there is the goo
[ stripped Cc line ]
On Thu, 2006-03-16 at 16:51 +0100, Rainer Gerhards wrote:
> > My 2 cents... Do the byte counting. Look at the headers of
> > pretty much any successful protocol (TCP, IP, UDP, etc) -
> > they all specify length of payload. Special character
> > sequence is really a hack IM
> My 2 cents... Do the byte counting. Look at the headers of
> pretty much any successful protocol (TCP, IP, UDP, etc) -
> they all specify length of payload. Special character
> sequence is really a hack IMO!
After some thinking, I agree with Anton. I, too, think that
octet-counting is supe
My 2 cents... Do the byte counting. Look at the headers of pretty much any
successful protocol (TCP, IP, UDP, etc) - they all specify length of payload.
Special character sequence is really a hack IMO!
Just to be clear, there was never any intention to allow multiple messages per
UDP datagra
Baszi,
> I see the following possible upsides of using some kind of framing:
> * byte-counted messages, effectively allowing the use of the full
> character set
> * application layer acknowledgements, avoid losing messages sitting in
> the TCP socket buffers without knowing that they were not rea
11 matches
Mail list logo
