VOEvent II summary, part 3

[Andrew Drake]

Hi,

On Mon, 19 Dec 2005, Alasdair Allan wrote:
>> It also seems likely that the iamalive mechanism will find use under more 
>> robust transport mechanisms, too.  We've run into the need for similar 
>> end-to-end delivery confirmation within archival data transport streams. 
>> An ack is likely a detail of a particular transport mechanism.  An iamalive 
>> is a reality check on the health of the endpoints of the conversation - a 
>> means for building confidence that when an alert does occur that the 
>> message will be heard.
>
> An IAMALIVE is not just testing the connection, it's testing the software at 
> each end, up to an including that software's DB etc. The complicated bit of 
> software generating a IAMALIVE message should do some sanity checks before 
> sending it, to verify it really is alive, correspondingly a bit of software 
> receiving an IAMALIVE should actually do some sanity checks before replying, 
> to make sure any messages it gets won't vanish down a black hole.

I don't think we are going to store imalives here, although this may be a 
good idea on short timescales. I have been sending imalives and acks with 
a slightly different format but it is simple for me to make them conform if we
are actually adopting this as an agreed standard?
I think the imalive notices should be reasonably frequent, much more so 
than events for the present time. I have adopted 1/min as per GCN.
I don't think we should mandate the frequency but I'd like to strongly
suggest many more than one per hour.
Perhaps Scott could comment on whether he has tried other rates with GCN 
connections?

How do the senders proceed when they don't get confirmation of imalives 
and event acks? It would be useful to make this a standard for 
interoperability.

>>> I thought we were changing the id element in VOEvents, but I'm probably 
>>> mistaken.
>> 
>> No, simply haven't had a second to think about what to call the new 
>> attribute.
>
> Oh, the id problem. That's an angle bracket problem, not really relevant. 
> Although we need a collective decision here since a few of us now have actual 
> parsers that are going to break when we make the change, what we actually 
> change it to isn't really very important.

Yes it is simple to change but I'd like to be sending and receiving and storing
conforming VOEvents ASAP, so it is relevant to me. The better our standards are
now the less everyone is going to have to change their software in the 
future.


Cheers,
       Andrew