Re: P2P Filesharing over UDP

--===============2042176506==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-Y76RA2kHQv7LtlUJcOJH"


--=-Y76RA2kHQv7LtlUJcOJH
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2005-06-19 at 15:04 -0700, Pyda Srisuresh wrote:
> [suresh] I am not sure, I understand you correctly in your above comment =
about
> assuming Full-Cone NAT. Is the following what you meant? =20

If both the publisher and subscriber know of each other, then any kind
of NAT works (the algorithm basically degenerates to STUN with port-
scanning to traverse symmetric NATs). If the publisher is unaware of the
subscriber then, as far as I understand, the publisher needs to be
behind a full cone since the application does not implement any sort of
out-of-band signaling to get the publisher to punch a hole for that
specific subscriber in his NAT. Not sure if I answered your question.

> > Basically, the approach trades off a public STUN server in exchange for
> > a port-scan and full-cone support.
> >=20
> [suresh] Right. If I understood what you said correctly, You dont need an
> external public server to get a list of file sharers behind NAT devices, =
when
> the NAT devices exhibit full-Cone NAT behavior.

I do not know how peers discover each other and find the file sharers.
You are correct in that Rodi does not have a central rendezvous server
(perhaps it has some gossip based discovery like gnutella, or the user
points it to the file server like in Bittorrent). What I was getting at
was that it doesn't use a public STUN server to discover its own
mapping.

> [suresh] Cool. This seems to add yet another voice to full-Cone NAT deplo=
yment
> in providing flexibility from a P2P application vantage.=20

True, but the only thing that supports full-cone is the port-scan. If
instead of the port-scan it implements a port-and-address scan then it
would work with restricted cone as well. That said, as Christopher and
David pointed out, port-scans are rarely welcomed by users and
administrators. =20

--=20
Saikat

--=-Y76RA2kHQv7LtlUJcOJH
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCuF66nFltqi691/oRAgRsAJ4xIJ7mFtOdTVEzBrtRrXJCfovcrACfSu+8
BTj8kMstVlc9etEG/wafc9Q=
=BXa5
-----END PGP SIGNATURE-----

--=-Y76RA2kHQv7LtlUJcOJH--


--===============2042176506==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline