Re: towards 0.2.1

Raimund 'Raimi' Jacob-Blödorn <[email protected]> Thu, 21 Mar 2013 06:33:52 +0100
Newsgroups gmane.network.serveez.devel
Message-ID <[email protected]>
On 03/20/2013 01:47 PM, Thien-Thi Nguyen wrote:

Hello!

> That is, the only TODO items are "Finalize B001[82]", reproduced here
> (excerpt from BUGS):
>
>    Bug:         B0018
>    From:        Stefan Jahn <[email protected]>
>    State:       unfixed
>    Date:        2000-07-01
>    Description: Cannot recompute the Linux kernel's checksums of larger
>                 (larger than a single MTU, fragmented) ICMP packets.  It
>                 seems like the defragmented user level packet (IP header)
>                 contains the checksum of the first fragment with its
>                 length and the More-Fragments-Flag set.

This one _might_ still be present. I see checksum errors nowadays when =

using wireshark to debug networking issues. However, that is hear-say.

>
>    Bug:         B0012
>    From:        Stefan Jahn <[email protected]>
>    State:       unfixed
>    Date:        2000-09-12
>    Description: If the server has many open connections with much traffic
>                 Linux starts deadlocking for some reason.  This
>                 corresponds with the occurrence of EWOULDBLOCK or EAGAIN
>                 on network sockets.  Seems that if one socket starts
>                 this, all want to do the same: nothing but wasting time
>                 in kernel space.  Errors happen to be on outgoing
>                 connections only.

I believe we forcefully made that happen with the 'mandel' demo and =

many, many clients. (on hardware 13 years ago...)

> I think these are very old bugs that manifest only on very old kernels,
> but maybe that's just wishful thinking.  (I haven't investigated.)

However, this might also be an algorithmic problem. there is a =

theoretical limit on how many client connections a server can handle =

with the traditional programming models: the c10k problem.

http://en.wikipedia.org/wiki/C10k_problem
http://www.kegel.com/c10k.html

As far as I can remember, that just might have been the problem.


> Stefan: Could you post test cases so that i might try to reproduce them?
> If i can't scrounge up test cases in the next week or two, i'll change
> the state to =91cant-reproduce-wont-fix=92 and release 0.2.1.

I doubt that he has the resources to do that. Just mark those bugs =

cant-reproduce-wont-fix and go on with life :)

	Raimund