Nate Lawson wrote:
> This is orthogonal to the original discussion
The original discussion was about whether or not to bloat a
structure to successfully contain, without overflow, a timer
interval stored in ticks instead of a fixed unit. 8-).
> but if you had a single
> system image, you use th
On Fri, 22 Nov 2002, Terry Lambert wrote:
> Nate Lawson wrote:
> > As a member of the e2e camp, I'd say that any device which is looking at
> > sequence space is implicitly an endpoint and has to accept the processing
> > limitations as such. MITM devices (load balancers, firewalls, etc.) are
> >
Nate Lawson wrote:
> As a member of the e2e camp, I'd say that any device which is looking at
> sequence space is implicitly an endpoint and has to accept the processing
> limitations as such. MITM devices (load balancers, firewalls, etc.) are
> IMO a poor workaround for the fact that most endpoin
On Thu, 21 Nov 2002, Terry Lambert wrote:
> Nate Lawson wrote:
> > On Thu, 21 Nov 2002, Terry Lambert wrote:
> > > FWIW: upping the roll-over rate is not a good reason to increase
> > > the size of fields, unless you want to increase the TCP sequence
> > > number filed to 64 bits? ...it has exactl
Nate Lawson wrote:
> On Thu, 21 Nov 2002, Terry Lambert wrote:
> > FWIW: upping the roll-over rate is not a good reason to increase
> > the size of fields, unless you want to increase the TCP sequence
> > number filed to 64 bits? ...it has exactly the same issues at
> > high data rates.
>
> That'
On Thu, 21 Nov 2002, Terry Lambert wrote:
> FWIW: upping the roll-over rate is not a good reason to increase
> the size of fields, unless you want to increase the TCP sequence
> number filed to 64 bits? ...it has exactly the same issues at
> high data rates.
That's what the timestamp option does
Julian Elischer wrote:
> On Thu, 21 Nov 2002, David G. Andersen wrote:
> > Are there compelling reasons not to change the socket buffer
> > timeout to a u_long from a u_short? This variable stores
> > the number of ticks before the socket operation times out.
> >
> > At present, the maximum SO_RCV
In article <[EMAIL PROTECTED]>,
David G. Andersen <[EMAIL PROTECTED]> wrote:
> Are there compelling reasons not to change the socket buffer
> timeout to a u_long from a u_short? This variable stores
> the number of ticks before the socket operation times out.
I already changed it from short to in
On Thu, 21 Nov 2002, Julian Elischer wrote:
> On Thu, 21 Nov 2002, David G. Andersen wrote:
>
> > Are there compelling reasons not to change the socket buffer
> > timeout to a u_long from a u_short? This variable stores
> > the number of ticks before the socket operation times out.
> >
> > -Da
On Thu, 21 Nov 2002, David G. Andersen wrote:
> Are there compelling reasons not to change the socket buffer
> timeout to a u_long from a u_short? This variable stores
> the number of ticks before the socket operation times out.
>
> At present, the maximum SO_RCVTIMEO or SO_SNDTIMEO value one
Are there compelling reasons not to change the socket buffer
timeout to a u_long from a u_short? This variable stores
the number of ticks before the socket operation times out.
At present, the maximum SO_RCVTIMEO or SO_SNDTIMEO value one
can set is SHRT_MAX / hz. With a 100Hz kernel, this comes
11 matches
Mail list logo
