[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pydonkey-general] Threading vs. Nonthreading
From: |
BuziFuzee |
Subject: |
[Pydonkey-general] Threading vs. Nonthreading |
Date: |
Sat, 02 Aug 2003 05:44:55 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) |
Okay, after having a few thoughts about pysocket, several questions came up:
1.) Bandwidth control
Bandwidth control can be applied very easily with the polling algorithm.
so the handle_read/write_event must return a number of how many bytes
read. The polling is be done until all up/down is excausted, but the
list is kept. Then the packet-processor-callback is started that
processes all the data collected. If after this there is time until new
bandwidth is avaiable, the prozess can wait or do anything else. If the
process takes longer, the amount of time he took longer is added to the
bandwidth. In worst case, this won't give a flat line, but it's much
more efficient.
2.) Priority connections
When someone wants a special file very fast the connections must have a
priority. Just solving it via amount of source clients is pretty dumb.
So we have to rewrite the map of the asyncore and the polling algorithm.
Further possibility is to give different amounts to read at the
recv-statement. So that high priority connections get all the buffers
they get, and lower connections only priority * n characters per poll.
3.) possible attacks
A detection must be added for someone sending garbled packets. So if
more then x % of the packets are garbled, the connection gets killed.
4.) threading the polling vs. serializing it
Maybe we should make an approach to multithreading. Not for every
connection, only for the basic elements.
I made a graphic, which shall make things clearer:

- [Pydonkey-general] Threading vs. Nonthreading,
BuziFuzee <=