pydonkey-general
[Top][All Lists]
Advanced

[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:

GIF image


reply via email to

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