first...DHT is used for files and other sorts of data, but keeping track of
users, at least in my system, does not happen.
you're close in that you have to carry around information concering your
firewall status (nody-ness)
when you start up, test the client configuration. You do this by connecting
to a server at ip-address #1,. Test both UDP and TCP, return the global-ips,
now, at the same time, the configuration server at ip #1 sends a message to a
hidden server located at another ip address #2 (behind the back pass). When
server #2 recieves the message it sends both a udp and tcp message (you make
up the data creating the message). to the client, When the client recieves a
message it set's boolean values expressing connectivity and open-ness.
you'll keep and send your global ip address' (one for tcp and one for udp)
(along with this info gathered at start up) in your messages; it will be used
later to connect with others.
there is a ole-school code writien by an MIT dude showing how to do this;
though, it's written rather poorly, like k&r c.
this is step one. start up.
step two is the heart beat server....oppps...i feel like gett'ns paid.
step three is connecting (aka blackmagic) but...and here's a hint...you can
develop your protocol on transfering info between nodes before implementing
this, given you have all the info, you just have to get them communicating. if
either one is open in anyway, tcp, udp, then you don't need to use "black magic"
lets just say, creating the messaging architecture will probably take a year
of more to develop...for example, routing, message relaying, search
i've done it...i took java, reversed engineered it, and proted it to C++.
then wrote a full implementation over that. Now i have a full UDP/TCP messaging
system for c++ and java, with encryption, all in a little engine that
continually says, "i think i can."
just remember, this is hard shit, and keeping it all together is half the
battle...the other half is debugging :)
here is sample code for the address used in my system:
#ifndef _Address_
#define _Address_
#include "Word.h"
// Address
class Address: virtual public InetSocketAddress {
public:
// constructor summary
Address();
Address(int port);
Address(InetAddress* addr, int port);
Address(InetSocketAddress* addr );
Address( Address* addr );
Address(String* hostname, int port);
virtual ~Address();
// method summary
virtual boolean acceptsUnsolicitedConnections();
virtual boolean acceptsSimultaneousOpen();
virtual boolean acceptsUnsolicitedMessages();
virtual boolean isSecure();
virtual void setAcceptsUnsolicitedConnections( boolean yesNo );
virtual void setAcceptsSimultaneousOpen( boolean yesNo );
virtual void setAcceptsUnsolicitedMessages( boolean yesNo );
virtual void setSecure( boolean yesNo );
virtual byte getProperties();
virtual void setProperties( byte props );
virtual String* toString();
static byte _ACCEPTS_UNSOLICITED_CONNECTIONS_; // 0x01 00000001
static byte _ACCEPTS_SIMULTANEOUS_OPEN_; // 0x02 00000010
static byte _ACCEPTS_UNSOLICITED_MESSAGES_; // 0x04 00000100
static byte _IS_SECURE_; // 0x08 00001000
protected:
void init();
byte mProperties;
};
#endif // _Address_
lemon
Michael Slavitch <[EMAIL PROTECTED]> wrote:
The proximity handling in Bamboo would most certainly stabilize proxy
selection for NAT traversal between endpoints. No need for STUN
there, it would greatly simplify the client as the client would learn
all it needs about itself from the DHT, as learned by others. The
DHT would tell the endpoint how best to punch holes, as the client
would have multiple observers. This also solves the multiple walled
garden problem.
All that is needed is a global bootstrap server, one that starts it going.
Am I close, Lemon? ;)
On 9/5/07, Lemon Obrien wrote:
> you want to do something really cool adam?
>
> i went bamboo for real.
>
> lemon
>
>
> Adam Fisk wrote:
>
> No ICE numbers yet, sorry. We're completing our ICE implementation now, and
> we've put the skeleton in for both UDP and TCP.
> I will say this, though. ICE is not so different from many RFC in the sense
> that it's fairly straightforward once you really take the time to get
> familiar with the algorithm. I see no reason it won't work in a good
> percentage of cases, but it doesn't get sneaky too with "symmetric" NAT
> traversal. It can handle some symmetric NATs, but it doesn't get into port
> prediction.
>
> It will be awhile before we have anything useful because I don't expect to
> have more than a few hundred users for a bit.
>
> -Adam
>
>
>
> On 9/1/07, David Barrett wrote:
> >
> >
> >
> > There was recently (July '07) a big discussion on this topic on the BEHAVE
> mailing list. I posted some of my results here:
> >
> >
> http://www1.ietf.org/mail-archive/web/behave/current/msg02496.html
> >
> > Basically, I can get about direct 90% peer connectivity using UDP. Rumor
> is Alex can get something like 99% (Alex â care to share any detailed
> numbers?). The IETF is pushing a protocol named ICE, but nobody knows how
> well it works (Adam â have you come up with any numbers yet?).
> >
> > Overall, it's much harder than it looks, even in the "simple" cases. The
> basic algorithm is:
> >
> > 1) Figure out the IP address of each node's NAT
> > 2) Share each node's pair of (LAN,NAT) IPs with the other node via some
> central server
> > 3) Try to connect over both the LAN and NAT addresses.
> > 4) Apply a lot of voodoo tricks
> > 5) Oftentimes it works
> >
> > Everybody seems to use a variation on this algorithm, though Alex recently
> made some suspicious comments suggesting otherwiseâ¦
> >
> > -david
> >
> >
> >
> > ________________________________
>
> > From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf Of Carlos Kamienski
> > Sent: Saturday, September 01, 2007 9:43 AM
> > To: [email protected]
> > Subject: [p2p-hackers] Effective TCP and UDP NAT Traversal (no relaying)
> >
> >
> > Dear all,
> >
> > I'd like to know what type of experiences you have about the rate of
> succesfull direct communications (without relaying) of peers behind NAT,
> both for TCP and UDP and for different scenarios, like home and corporate
> users.
> > There are some results reported like the one for STUNT
> (http://nutss.net/pub/imc05-tcpnat.pdf),
> which says that "TCP NAT Traversal can work 85%-90% of the time" (
> http://www1.ietf.org/mail-archive/web/midcom/current/msg03848.html).
> > However, other reports don't seem to be so encouraging, like
> http://www.paradial.com/storage/Elements/CallCompletion.pdf
> .
> >
> > What are the best approaches for TCP and UDP? STUN, STUNT, ICE,....?
> >
> > The thing is that we need peers to establish direct communication (no
> realying) for both TCP and UDPand I like to know the best approaches to do
> that and the best existing solutions for that.
> >
> > Thanks
> >
> > Carlos
> >
> > --
> > "There's no sense in being precise when you don't even know what you're
> talking about."
> > John von Neumann
> > _______________________________________________
> > p2p-hackers mailing list
> > [email protected]
> >
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
> >
> >
>
> _______________________________________________
> p2p-hackers mailing list
> [email protected]
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
>
>
>
> You don't get no juice unless you squeeze
> Lemon Obrien, the Third.
>
> http://www.tamago.us
> _______________________________________________
> p2p-hackers mailing list
> [email protected]
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
>
>
--
Michael Slavitch
Ottawa Ontario Canada
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
You don't get no juice unless you squeeze
Lemon Obrien, the Third.
http://www.tamago.us
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
