On 04.04.2013 23:52, Kevin Day wrote:
On Feb 1, 2013, at 5:09 PM, Andre Oppermann wrote:
I'm working on a solution. Have to make sure that the chance to
crack a reduced cookie during its 30 seconds lifetime isn't too
high. That means involving our resident crypto experts for
verification.
On Feb 1, 2013, at 5:09 PM, Andre Oppermann wrote:
>
> I'm working on a solution. Have to make sure that the chance to
> crack a reduced cookie during its 30 seconds lifetime isn't too
> high. That means involving our resident crypto experts for
> verification.
Hey, Andre!
I know the securi
On 01.02.2013 23:54, Kevin Day wrote:
On Feb 1, 2013, at 4:39 PM, Andre Oppermann wrote:
This is not true. FreeBSD uses bits in the timestamp to encode all recognized
TCP options
including window scaling.
Sorry, you are correct here. Reading through a half dozen TCP implementations
in t
On Feb 1, 2013, at 4:39 PM, Andre Oppermann wrote:
>
> This is not true. FreeBSD uses bits in the timestamp to encode all
> recognized TCP options including window scaling.
>
Sorry, you are correct here. Reading through a half dozen TCP implementations
in the last day trying to figure out wh
On 01.02.2013 22:21, Kevin Day wrote:
We've got a large cluster of HTTP servers, each server handling >10,000req/sec.
Occasionally, and
during periods of heavy load, we'd get complaints from some users that
downloads were working but
going EXTREMELY slowly. After a whole lot of debugging, we na
On Feb 1, 2013, at 4:05 PM, Ed Maste wrote:
> On 1 February 2013 16:21, Kevin Day wrote:
>> We've got a large cluster of HTTP servers, each server handling
>> >10,000req/sec. Occasionally, and during periods of heavy load, we'd get
>> complaints from some users that downloads were working but
On 1 February 2013 16:21, Kevin Day wrote:
> We've got a large cluster of HTTP servers, each server handling
> >10,000req/sec. Occasionally, and during periods of heavy load, we'd get
> complaints from some users that downloads were working but going EXTREMELY
> slowly. After a whole lot of deb