THanks for replying. Comments below.  HF

----- Original Message -----
From: Bernard DelmñÆ <bdelmee / advalvas.be>
Newsgroups: comp.lang.ruby
To: ruby-talk ML <ruby-talk / ruby-lang.org>; <undisclosed-recipients: ;>
Sent: Sunday, September 16, 2001 7:00 AM
Subject: [ruby-talk:21259] Re: Peer-to-peer


>
> "Hal E. Fulton" <hal9000 / hypermetrics.com> wrote:
>
> > Suppose I wanted to implement a Napster-like
> > server whose purpose was to enable
> > communication between peers. How do I get
> > the clients to talk?
>
> Well, I have never programmed anything network-related in ruby,
> nor sniffed Napster packets, but here's a reasonable (albeit probably
> naive) scenario:
>
> [1] client B contacts server A (on a well known port), publishes
> list of shared files, and _port_ on which it's listening and willing
> to serve peer requests
> [2] client C contacts server A (on same well known port), requesting
> a file. Server discovers a match in B's list, and directs C to B's
> listening port. (I don't mean automatic redirection, C needs to
> explicitly contact B on its advertised port)
> [3] C serves request(s) on published port

This seems reasonable. I guess there are synchronization issues,
though... it's no trouble to handle it in the (central) server, but I'm
wondering if there will be a problem synching the clients with each
other.

I'm actually not thinking of file-sharing, but of a game. So once the
server informs each client of the other's identity, there has to be
some protocol for determining who goes first. I could cheat and
let the server set it randomly, of course...

> Of course clients could be listening/serving on a default ("well
> known") port, but that'd be overrideable. Handy when for example,
> B and C (and A for that matter) all run on the same computer.
> In TCP/IP parlance, no two processes are allowed to bind/listen
> to the same port on the same system. (the second would get an
> "address already in use" error or such)  So a mere IP address
> does not identify a communication endpoint; the combined IP:port
> does.

OK... so I'm thinking I could start with a port like 12345, and try it...
iff another process is using it, I'll get an error, and I can increment it
and try again until I get a success (or find that I've tried  an
unreasonable number of times).

> Also note that clients are actually servers as well (P2P), so
> threading probably is in order (since your server duty may take a
> while to satisfy a slow client request).

Yes, that makes sense.

Thanks,
Hal