Re: Presence service
"Mark S. Petrovic" <[email protected]> Tue, 5 Dec 2006 17:59:44 -0800
| Newsgroups | gmane.comp.java.jxta.user |
|---|---|
| Message-ID | <20061206015944.GE815@false> |
On Tue, Dec 05, 2006 at 05:52:03PM -0800, Walter Barnes wrote: > This is interesting.... > > I think I understand the part about the propagate pipe being well-known > so that new peers can announce their presence. But how do the other peers > reply? Do they use the same progate pipe (I don't think so, not sure) > or some other well-known pipe? All peers bind to the same propagate pipe - which has a single-valued, unique pipeid. The turnkey private rendezvous/node (see the MyPeer.java code) we've been talking about coincidentally does exactly this. Any message written to a propagate pipe by a member of the peergroup is received by all peers in the peergoup. It's sort of like multicast on a peergroup-scope. > Also, this takes care of when a new peer comes online, but what about > when a peer goes away? Should peers use the propagate pipe to send a > "heartbeat signal" or should peers periodically check in on the peers > they know about? Yes, you can issue a 'goodbye' when a peer leaves in a controlled manner. I've also implemented timestamps on the corresponding 'hello' messages, such that peers that die abruptly can be removed from the 'present' list by the rest of the peers in the group via a periodic sweep through the 'present' list, looking for 'hello' messages that have not been refreshed or some such. Sort of like a watchdog timer. You get the idea. Mark > Thanks, > Walter > > ----- Original Message ---- > From: Mark S. Petrovic <[email protected]> > To: [email protected] > Sent: Wednesday, December 6, 2006 12:47:20 AM > Subject: Re: [JXTA user] Presence service > > > On Tue, Dec 05, 2006 at 05:37:56PM +0100, [email protected] wrote: > > Thanks for your response! > > If I am using the propagate pipe I only need to create it by using the > > peer groups pipeservice, there is no need to publish it in the group or > > create it on the Rdv first, right? > > Correct. What you are describing is essentially the technique of using a > "well-known PipeID", whose analogue I'm sure you've heard of with things > like SMTP, HTTP, and other important Internet standard services. There, > they are call well-known port numbers. > > Well-known in our case means all peers know the PipeID a priori to its > use. Meaning it is available as an application constant or declaratively > configured somewhere in a config file. There is no point publishing it > for the sake of discovery - just hard code it somewhere in your app --- > because you already know you will need it. > > hth > > Mark > > > Vince > > > > > > Mark S. Petrovic wrote: > > >Vince, your propagate pipe idea is a good basis for a presence service. > > >I travelled the same path you did, first wanting to use advertisements, > > >then concluding that I wanted something more deterministic. A propagate > > >pipe is the price you pay for knowing quickly peers are out there, > > >rather than assuming they are not on some unknown timescale if you cannot > > >discover their advertisements. > > > > > >On Tue, Dec 05, 2006 at 11:37:15AM +0100, [email protected] wrote: > > > > > >>I implemented a presence service for my application a few weeks ago but > > >>it is much too slow and unreliable and I want to implement it different > > >>this time and would like to hear your comments. > > >> > > >>My current implementation is based on advertisements that are published > > >>every 5 minutes using a timer task such as Brendon J. Wilson is doing it > > >>in his book. Other peers are searching for these advertisments with a > > >>timer task. So the problem with this is that it can take up to a few > > >>minutes until a peer is found to be online and a peer could go offline > > >>and it is not recognized. So I definitely need to change this. > > >> > > >>My new approach would be a mix of advertisments and a propagate pipe. > > >>The advertisment is published to the peer group with an application > > >>specific description of the peer. This advertisment for example holds a > > >>pipeadvertisment for a JxtaSocket which is later used to transfer files. > > >>When a peer enters my peer group it searches for the advertisments of > > >>other peers so that they can be displayed in the GUI as offline. It also > > >>sends a "hello" message to all other peers in the peer group with its > > >>status such as "online" and gets a response from all other devices that > > >>are online too. > > >> > > >>Do you have any other ideas on implementing a presence service? > > >>How did other applications solve this? > > >> > > >>thanks in advance, > > >>Vince > > >> > > >>--------------------------------------------------------------------- > > >>To unsubscribe, e-mail: [email protected] > > >>For additional commands, e-mail: [email protected] > > >> > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > -- > Mark S. Petrovic > Pasadena, CA > http://www.petrovic.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > ____________________________________________________________________________________ > Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] -- Mark S. Petrovic Pasadena, CA http://www.petrovic.org