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

[Joël Vennin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

But currently is it done ? With the common.protocol ? But sure we can do it 
without the twistedmatrix depends ... But we need to do a good design to be 
able to limit the connection. So we can use the standart asynchronous socket 
library (asyncore default in Python).

>
> 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.
What do you call with client/server operation ? I think we need to be more 
abstract if we want support another protocol in the future.

                   Protocol
               //                   
              //                     
            EdonkeyProtocol     
              //                       \\
EdonkeyClientProtocol   EdonkeyServerProtocol

Or something like that. The same about information, packet format .....


                          Information
                          //              
            EdonkeyInformation    
                   //                      \\
EdonkeyClientInformation       EdonkeyServerInformation


              Packet
           //              
     EdonkeyPacket          


        


> 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.
Sure, but the first, it's the client, when the client is done we concentrate 
our effort on the server side...

> 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.
No other solution if we want a good design...

> >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 an UML representation, just a diagram class is necessary.  It's 
usefull to have a graphics representation of our works and it's more easier 
to design better our works So. Just for diagram representation Dia is good 
....
Before coding, it's more important to design it, so we can work together and 
we can know easily the todo work .... 

> >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.
I'm totaly agree with you, server.met is "important" because lot's of people 
propose this file. And propose a XML file is a good think ... So all our 
files wil be XML format... 

>
> 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.
Yes sure i've lot's idea too on this possible work... (but the server after 
the client ;)


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

> Okay, the traffic would be quite big. Maybe we should use the
> distributed hash-table algorithm or something like that.
Sure but not for now ... ;)

> But that's music of the future.
Hehe :)

> 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.
Yes, sure we can remove the matrix depends, we can use as i said above, the 
asyncore module but we need to add some feature like limit the bandwidth for 
a group of connection and limit bandwidth for all connection too .....


So How Start ???

We need to build a strong connection manager using asyncore module. Next we 
can discuss and code some little part, as the Protocol class, 
EdonkeyProtocol, ....

This night i'll try to create a first UML representation with dia, I'll put it 
on the cvs.

I wait your suggest ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+wncDOzJ7itUoJpQRAnB6AKCBnqNpIXCJw8gz0p3jeZngOQkdPgCcDUhH
PSVkeRTP+C1xA9wUM/QJ0V4=
=eGOL
-----END PGP SIGNATURE-----