Re: [Pydonkey-general] Current stuff ...

[BuziFuzziii]

Hi!

Okay, let's get things running! ;)

First of all, big compliment for the work which is already done!

Now a few thoughts, that I had:

1.) Maybe we should make a little library (class) which can send/receive 
every kind of eDonkey packets. This could be mainly based on the 
Common-Tree you already made. This would be the lowest layer.

2.) Based upon this, there should be two classes, one which contains all 
client operations, and one which contains all server operations. This 
would be the middle layer.

3.) Based upon this, there should be the server-main-class and the 
client-main-class which is quite similar to the server.exe and the 
client.exe like edonkey, but shouldn't have any user-interface.

4.) Based upon this we could do user-interfaces what ever we want.

Yes, I know, it's almost like that, what is already existing, but it 
should be more blackboxed.

I agree completely, that the GUI comes last and that we should 
concentrate on the basic functions first.

> All parts need to be improve, we need to document the code, and change a lots 
> of code ;) About ClientInformation in donkey.client, maybe we need to move 
> some ClientInformation in a new class in common.client ?
>
> The current problem is that emule client doesn't send a QUEUE RANK when our 
> client send a slot request ....
I don't know if you use a packet sniffer, CommView is very good, I 
could have a look on the problem, when we have all other work done.

> We need use a UML tool to design or redesign our client ...
Hmm, I must say that I'm not a great fan of UML because it makes nothing 
easier in my point. But that's my view.

> I think we must concentrate our efforts on the core not on a GUI ...
>  
Right!

> I'm asking several question about file. Do you think we must respect .met, 
> .part file format or create another format ?
>  
I would say, we only need the server.met. And the server.met should only 
be "imported" and we convert it to our format, because the 
server.met-Format is not very comfortable. I would say, that we 
introduce another format (in XML?), that can have real domain-names too, 
because of the dynamic-ip servers, which have no chance with the actual 
server.met.

And I would go another step forward: My idea is, that our eDonkey-Server 
is a distributed one. That means, that pyDonkey-Servers could build an 
internal network, where they exchange their sources. Every server holds 
a database with the sources of all other servers, that are in that clique.

So, you don't need any big Lugdunum-Servers with 100000 users to get 
good results. Because of our new server.met-Format, maybe a hundred of 
dynamic-ip servers with 5000 users each, could have together 500000 
Users and millions of files. We could use the python databases for that. 
Okay, the traffic would be quite big. Maybe we should use the 
distributed hash-table algorithm or something like that.

But that's music of the future.

Let's concentrate on the basic functions of eDonkey protocol first.

Another point are the libraries that are used at the moment. I don't 
now, but dumb-users could have problems installing the libraries. So 
maybe we should rely on the basic python-socket-stuff at least for the 
client. I don't know how much better the twistedmatrix-library is, and 
if it's possible at all to establish a stable program with standard 
socket library. I used it with 100 connections already, but who knows.

> Any suggest are welcome ...
Here you are,
Spikeee ;)