Problems and limitations

[GoogleCodeExporter]

The problem can be reproduced running the provided EchoServer sample.

Cogen version 0.1.7. Using Windows (XPsp2) and Linux (Ubuntu 7.10 2.6.22-14).

1) On Windows, using the IOCP reactor, the maximum connection number one
server can accept is 3960. On Linux, using the EPOLL (I suppose), the
maximum is 1020.

2) On Windows, the server incorrectly sends then same text out to different
connections (sockets). You can reproduce it by simply adding the client
address:port to the "WELCOME" string. On Linux it works as expected.

3) On Windows, the server issues warnings (below) when a connection is
closed by the client without the "exit" command (i.e. the client just
closes the 'telnet' window). It doesn't happen on Linux at all.

c:\Python25\lib\site-packages\cogen-0.1.7-py2.5.egg\cogen\core\reactors.py:577:
UserWarning: O nome da rede especificado não está mais disponível. on
<ReadLine at 0xBCBDF0 sock@0xBC9570 P:0 L:0 B:None to:None>/<handler
Coroutine instance at 0x00BCBDA0 wrapping <generator object at 0x00BD02D8>,
state: RUNNING> ctypes.FormatError(rc), op, coro), stacklevel=1

4) Yet on Windows, the server many times just can't detect the remote
'close' event, i.e. when the client closes the telnet window, the server
doesn't aknowledge it sometimes (not all times).

Original issue reported on code.google.com by rreg...@gmail.com on 2 May 2008 at 3:38

[GoogleCodeExporter]

1. The maximum connection number is mostly related to system limits - have you 
tried
changing them ? there a ulimit command for linux and for windows there are a 
lot of
limits (since xp it's not a server os) like the hardcoded limit in tcpip.sys 
(sp2),
MaxUserPort setting and some other settings that i don't know of. You might 
want to
get a server windows os.

2. I wish you would try the trunk version - there had been a lot of fixes.

3. That's for debugging purposes, the windows networking stack is very 
different from
the linux one. I'll remove that warning in some future verion.

4. You shouldn't rely on that behavior (since it's very dependent on the 
platform)
and instead use timeouts.

Still, I urge you to get the trunk version.

Original comment by ionel...@gmail.com on 2 May 2008 at 11:19

[GoogleCodeExporter]

Also, for the issue 1, there are TcpNumConnections, ReservedPorts, 
TcpTimedWaitDelay,
MaxFreeTWTcbs, MaxFreeTcbs settings for windows that have impact on the number 
of
connections. The event log should offer some helpful information too.

Original comment by ionel...@gmail.com on 2 May 2008 at 11:25

[GoogleCodeExporter]

Thank you so much for such a quick reply! :-)

1. I will try to change the 'ulimit' on Linux, and will use a Windows 2003 
Server
instead of XP and try it out.

2. Will get the trunk version.

3. Ok.

4. I noticed sorta 'settimeout' function that I supposed was made for this. 
Does it
apply to server sockets as well? 

Original comment by roger.py...@gmail.com on 2 May 2008 at 1:08

[GoogleCodeExporter]

4. there are a bunch of ways to use timeouts

You can set it globally for the sockets module.
{{{
from cogen.core import sockets
sockets.setdefaulttimeout(<float value>)
}}}

You can also set the timeout per socket wrapper (the sockets.Socket class), 
otherwise
it will use the timeout from the previous example.
{{{
from cogen.core import sockets
mysock = sockets.Socket()
mysock.settimeout(<float value>)
}}}
These are made to be very similar the the standard sockets for compatibility 
purposes
- also, should help porting some code :), but what actually happens follows:

You can enforce a default timeout per scheduler: 
{{{
from cogen.core import sockets
from cogen.core import schedulers

...

sched = schedulers.Scheduler(default_timeout=<float value>)

...

}}}
If you do set a default_timeout in the scheduler all the socket stuff that is 
runned
though that scheduler and doesn't have a explicit timeout set (eg
socket.accept(timeout=10) or socket.accept(timeout=-1) or a timeout set with
setdefaulttimeout or settimeout) will have the default_timeout from the 
scheduler -
also, -1 means no timeout even when the scheduler has a default one.

Original comment by ionel...@gmail.com on 2 May 2008 at 2:16

[GoogleCodeExporter]

Original comment by ionel...@gmail.com on 5 May 2008 at 7:36

• Changed state: Invalid