Subject: npds Digest V1 #9

From: Listar <nospam_listar_at_ml.free_dot_fr>
Date: Mon, 13 Nov 2000 03:18:59 +0100 (CET)

<x-charset x-mac-text>------------------------------------
npds Digest	Sun, 12 Nov 2000	Volume: 01  Issue: 009

In This Issue:
		[NPDS] [Protocol Draft] SHARE & QUERY - Or a network of trac

----------------------------------------------------------------------

Date: Sun, 12 Nov 2000 23:22:20 +0100
From: Paul Guyot <nospam_pguyot_at_kallisys_dot_net>
Subject: [NPDS] [Protocol Draft] SHARE & QUERY - Or a network of trackers?

Hi all,

Since I worked a little with Victor on his java tracker server, I 
decided to resume the work on the protocol draft waiting for my 
Newton to come back in order to work on the ATA Support.

The draft is available at:
http://eddie.cis.uoguelph.ca/~victor/npds/NPDS_Protocol_1.1.html

And all contributions are welcomed.

I was thinking about the SHARE & QUERY commands which were defined 
for historical reasons. (With Victor, we are working on the SHARE 
bug).

Here's the plot: the trackers can share with others the Newtons they 
know to be up. This feature was actually designed by Matt.

Now, from that, I think that a good idea would be a network of 
available trackers, each sharing with each others the Newtons that 
are up. I also thought about a method of telling the Newtons which 
became orphans that their tracker died and offering them to register 
on ourself.

With that, we'll have a strong network of trackers. (I admit that 
this idea is probably not worth it for our faithful Newtons, but I 
like the idea of a strong network for the Newton's sake).

Now, this means some changes in the SHARE and QUERY methods. If I 
understand what we drafted in July-August, the SHARE command is for 
servers registered on a tracker and QUERY for them all. This doesn't 
seem really worth it having two commands since it's better to know 
all Newtons another tracker knows, even if those Newtons were not 
registered on it. However, we need a command to know all data about 
Newtons, such as the Hash (unimplemented and even not documented - a 
unique hash of the unique ID to identify a Newton, so that we could 
have ICQ like icons) and the tracker this Newton is registered on.

However, we need a command for the Web Pager future design of getting 
access to someone's Newton: I thought that we could have a built-in 
dialog to send a message on the Web Pager and both bookmarks (well, 
simply recents first) and a button to download the list of currently 
up Newtons. For that, we need a simplified command, we don't need the 
last verification date, the status is maybe worth it, and we of 
course need the description and the URL.

I think that the best would be to keep SHARE for the first command 
and QUERY for the second.

Now, we'll have to choose when the sharing is done.
Here is a suggestion: (we could stick on what's currently half 
implemented in Victor's tracker)

A tracker server has three tasks:
- waiting forever for commands as described in the protocol
- verifying periodically that registered Newtons are alive
- calling other trackers periodically about the Newtons they know. By 
calling a tracker, a tracker tells the other it exists. A tracker 
should maintain between resets a list of trackers it knows, and for 
example have a mechanism like if a tracker is down for too long a 
time, it is removed from the list. The developer should create some 
interface to edit this list (e.g. Victor's console).

When calling a tracker, the tracker looks into the list of Newtons it knows.
If the tracker is down, it notes all the Newtons it knows belonging 
to this tracker as orphan.
Otherwise:
If the tracker claims a Newton, it updates the list (either changing 
the owner of the Newton and therefore clearing the orphan flag or 
creating a new entry)
If there are Newtons the tracker knew to belong to the tracker it 
called and that the tracker didn't declared as up again, it removes 
them from the list.

Then, it processes all orphan Newtons and calls them telling them 
announcing them the bad news and offering its services. It then 
clears the list.

On the client side, when receiving such a bad piece of news, the 
Newton adds this tracker in its known tracker list. If it is the 
first time it heard about the bad news, it answers "Yes, please 
register me" and notes that it now belongs to someone else. If it 
isn't the first time, it says "Thanks Pal, but I already belong to 
XXXX" giving the tracker an opportunity to grow its list.

Sounds a little complex, but well, I'm just waiting for your 
agreement to document it and implement it with Victor. Of course, I'd 
prefer first some comments.

[Victor: about the GMT bug: Misato seems to have the same problem as 
G3. Any idea?]

Regards,

Paul
-- 
Attention, nouvelle adresse.
New address, please update.

------------------------------

End of npds Digest V1 #9
************************

</x-charset>