[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: BuziFuzziii
Subject: Re: [Pydonkey-general] Current stuff ...
Date: Wed, 14 May 2003 16:15:27 +0200
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0


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 ...

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 ;)

reply via email to

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