dev-serveez
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dev-serveez] towards 0.2.1


From: Raimund 'Raimi' Jacob-Blödorn
Subject: Re: [dev-serveez] towards 0.2.1
Date: Thu, 21 Mar 2013 06:33:52 +0100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

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 <address@hidden>
   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 <address@hidden>
   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 ‘cant-reproduce-wont-fix’ 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]