News for hackers. Stuff that matters.
Re:Upstreaming multipath TCP by mehrdadn on Friday September 27, 2019 @06:35AM (#21090363)
> TCP keep alive has a minimum of 2 hours or so. Debugging can live with that.

If the "minimum" was 2 hours then e.g. MSDN wouldn't be recommending that it be configured to 5 minutes would it? https://docs.microsoft.com/en-us/previous-versions/windows/i...

> And debugger ruins everything; If the other side sends something larger than the local receive buffer it will usually disconnect after a while. as it will sense no one on the other end.

"Everything"? Well when data isn't being sent then the connection could live on as long as it's kept alive by the kernel, right? Whereas with a userland implementation even that possibility becomes difficult.

You seem really intent on making unfounded blanket claims to rebut my point... but I feel like there's some validity to the point I'm making? It's be more helpful to see if you can instead find parts of it that might have some truth to them.

> It's just that historically, unix/linux/NT don't.

Yeah, hence why this approach seems problematic...

Re:Upstreaming multipath TCP by namibj on Friday September 27, 2019 @07:22AM (#21090646)
Use Mozilla's rr. Record the offender, then debug offline.
Re:Upstreaming multipath TCP by mehrdadn on Friday September 27, 2019 @09:10AM (#21091526)