pydonkey-general
[Top][All Lists]
Advanced

[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






reply via email to

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