VOEvent II summary, part 3

[Alasdair Allan]

Andrew Drake wrote:
> Alasdair Allan wrote:
>> Rob Seaman 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'm currently not storing them, later (towards the end of the week) I'm 
going to do some work to strip the timestamps and get an idea of my 
round trip statistics between eSTAR and RAPTOR.

>  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 that was the decision of the mini-interop, subject to the 
review and agreement of everyone else. It seems pretty sensible to me, 
and I haven't really heard any arguments against yet?

Do you have a TCP socket up and running I can point my broker at? If so 
mail me off list and we'll try and connect everyone up...

> 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.

Ditto, there is a 1 per minute flow between myself and TALONS.

> I don't think we should mandate the frequency but I'd like to strongly 
> suggest many more than one per hour.

Agreed.

> Perhaps Scott could comment on whether he has tried other rates with 
> GCN connections?

I'd be interested in finding that out?

> 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.

Err, that's an interesting question. Drop the socket connection 
presumably? It's then up to the client to reconnect?

>>>> 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.

Whereas I've got the operational outlook of having something working 
now that isn't entirely standards compliant is better than having 
something working next week that is, so long as the semantics and the 
meaning of the attribute doesn't change this one at least isn't a big 
deal.