[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pydonkey-general] Weakness in pysocket
From: |
BuziFuzee |
Subject: |
[Pydonkey-general] Weakness in pysocket |
Date: |
Thu, 31 Jul 2003 21:51:28 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) |
Hi Joel,
today I checked out pysocket and read it. Really nice work!
But I think a found a weakness in scheduling algorithm:
Let's say you have 100 Connections, and the bandwidth limit has been
reach at connection number 10, the other 90 connections won't be able to
transfer. In the next round again. So maybe connection 88 will never be
able to send a packet.
To solve this problem easily, just make something like this:
in manager.py:
randy=random.Random()
lenr=len(r)
while (lenr > 0) and not (uploadbandwidthexcaused() and
downloadbandwidthexcaused()):
i=randy.randint(0, (lenr-1))
(fd,flags)=r.pop(i)
lenr-=1
# -----------------from here no change
try:
obj = self.__map[fd]
except KeyError:
continue
try:
if (flags & select.POLLIN):
obj.handle_read_event()
if (flags & select.POLLOUT):
obj.handle_write_event()
#except ExitNow:
# raise ExitNow
except:
obj.handle_error()
Another thing is that you don't have do go any further if the bandwidth
is for the moment excaused.
Only question: aren't buffers overflowing then, if we don't collect the
packages?
Otherwise they'll put to the queue. But won't that queues get really
large? And isn't it vulnerable to flooding attacks, so that buffers will
overrun?
Cheers,
Spikeee
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Pydonkey-general] Weakness in pysocket,
BuziFuzee <=