[mnet-devel] EGTP-based P2P Questions

[Zooko O'Whielacronx]

Welcome, Adam!

> Question 1) Has anyone done this recently, and if so, what are the 
> issues?

No, nobody has done it recently.

The issues are not deep -- EGTP does not in any sense depend on the file
storage, content tracking, the XML-RPC interface, or other parts of Mnet.  The
issues, if any, are shallow, having to do with in which subdirectory a file
should be located.


>    Once EGTP can be invoked from a standalone python program, we plan to 
> write a wrapper that will allow us to embed EGTP within our C++ client 
> application.  The plan (suggested by Zooko) is to release the wrapper 
> class(es) under the GPL.  We'll be using them commercially; anyone else 
> will be free to use them non-commercially.

Just to be precise, the GPL doesn't prohibit "commercial use" of works derived
from your source code, it only prohibits "closed-source distribution" of such
works.

Coincidentally, three companies just put out a joint press release proclaiming
their success in the business model of releasing their source code under the
GPL and then charging a licensing fee for people to use their code under a
different license:

http://www.mysql.com/press/release_2004_10.html


>    We hope that eventually there will be millions of people running our 
> client software.  The vast majority of those will be NATed home users.

:-)


> Question 2) Correct me if I'm wrong, but these nodes would probably not 
> be able to act as EGTP supernodes.

They *can* act as relay servers, and rarely there may be some actual reason for
them to do so, but generally there isn't, and they don't.


> Question 3)  Does anyone have a sense of how many supernodes would be 
> required to facilitate communication among N non-supernodes, with N 
> between 100,000 and 10,000,000.

If either the ultimate recipient *or* the sender are able to receive incoming
TCP connections, then they will do so, bypassing the relay server entirely
after the first message, or the first few messages, go through the relay
server.

Else, if both the sender and ultimate recipient are unable to receive incoming
TCP connections, and both are on-line at the time, then the relay server acts
as an immediate proxy, so the limiting factor is the relay server's bandwidth.
If its bandwidth is asymmetric, you should think of the lesser of the two, so a
relay server behind a 1.5 Mbps down/256 Kbps up ADSL line can proxy no more
than 256 Kbps.

Else, if the recipient is off-line, then the relay server stores messages in
RAM.  This is intended only for short-term storage, for example if the
recipient is spending a few seconds or a couple of minutes redialing its modem
in order to reconnect, or something like that.  As it is stored in RAM, and as
RAM is limited, such messages get dropped by the relay server if there get to be
too many of them.

So I think the basic constraint is the bandwidth of the relay server.  If each
node needs to transmit 1 Mbps to a friend 24x7, then a relay server which has
less than 1 Mbps bandwidth is useless (in the current design...).

In practice, the needs of the endpoints are bursty, and so the above example
doesn't actually happen.

There may be a question of how relay server failover is done.  Currently, the
end-points choose their relay server via a complicated algorithm of its
historical performance and its recent availability.  This hasn't been proven to
handle relay server overload in practice, and might need some tweaking.


>    For legal deniability purposes, we would like not to be running the 
> supernodes ourselves.  That is to say, it's conceivable that users of 
> our software might use it to share copyrighted content.  If they do so, 
> we'd rather not know about it.

All EGTP traffic is encrypted so that only the ultimate recipient can read it.

 
> Question 4) What are the requirements for running a supernode?

The requirements for running a relay server are just the requirements for
running EGTP at all.  The requirements for running a *useful* one are less
certain.  The first bit is that if you can't receive incoming TCP connections
you shouldn't run one (in your application at least).  After that, it might be
best if everyone ran one and the relay clients chosen among them according to
their own criteria.

For example, a relay server on a 56 Kbps modem might appear to be
worse-than-useless to most relay clients, but a relay client on a 28 Kbps modem
(and operated by a patient human) might be glad to have it, especially if the
more powerful relay servers are busy with other clients...


Regards,

Zooko



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel