Re: Presence service

I have prescribed the following as a stopgap presence mechanism, and I 
thought I would share here as well

- Create a mechanism given a node name, a propagated pipe can be 
independently created by interested parties
  (See the various pipe creation methods under NetworkManager under 
http://shoal.dev.java.net)
- At start up, a nodes listens on it's encoded pipe for presence queries.
- After startup, and after a connection to a rendezvous, a node emits a 
presence message over it's encoded presence pipe
  - The message contains presence related info including bidirectional 
channel identifiers
- Interested nodes subscribe to the presence list pipe IDs
  -(after receiving the announcement, or response to a query)
  -create a JxtaSocket/JxtaBiDiPipe for presence purposes (heart-beat 
and event notification)
- Interested nodes, periodically (2-5 minutes) emit a query for absent 
nodes

Also keep in mind that a propagated pipe can be used as a unicast pipe 
(simply create and output pipe with a specific PeerID, 
JxtaMulticastSocket is a good example).

Relying on propagated pipes as described above, distributes the load 
amongst the rendezvous nodes and would probably work well for short 
presences lists (due to the maintenance of the bidi channels).

Ultimately, a scalable presence service which relies on SRDI, resolver, 
peerview, and walker for publish/subscribe, and location optimal mapping 
of indexes ought be pursued.  I think both a stopgap solution, as well 
as a formal presence service should be pursued under the presence projects.


Mohamed





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?
>
> 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?
>
> 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]
>>     
>
>