120 likes | 207 Views
Transporting VOEvents. Andrew Drake, Matthew Graham, Roy Williams, et al. GCN VOEvent prototype. Concept: Modify Scott's socket_demo.c to send VOEvents. Why? GCN VOEvents should be sent from GSFC without interruption. Familiar code starting point.
E N D
Transporting VOEvents Andrew Drake, Matthew Graham, Roy Williams, et al.
GCN VOEvent prototype Concept: • Modify Scott's socket_demo.c to send VOEvents. Why? • GCN VOEvents should be sent from GSFC without interruption. • Familiar code starting point. • Make a small client to send just VOEvents for possible future switch to VOEvents alone.
GCN cont. Code. Transform GCN packets to VOEvents. • Write VOEvent xml string over TCP • Events can be sent with modified version GCN socket_demo. No additional libraries. Single function call. Or... • From a file with a small client. Server to receive VOEvents • Acknowledge receipt to client • Creates a Webpagewith event links • RSSfeed • DataScope link
Possible Problems • Errors. Limited error checking (include a hash). • Security. Events sent as plain text. • Delays. Many subscribers/events could cause connection delays. • Lost notices. Currently single socket connection. • Data content needs to be checked for errors. • What about GCN circulars as follow-up VOEvents?
A Second Approach • Send converted GCN packets over Jabber • Jabber XMPP • An open, secure, decentralized, and extensible IM service. • Client-Server (email like) arch but aware of user presence. • Presence connected (listening, ignoring), not connected, do not disturb. • Clients connect with TCP (socket 5222 or 5223) • C2s one-way XML stream, s2c separate stream • Messages sent as XML snippets (stanzas). • Each user unique JID node@domain/resource.
PubSub (JEP-60) • ~80 Jabber clients and 15 server code library sources available (most GPL) in Java, C#, PHP, C, C++, Python, Perl, etc. • However, plain IM lacks subscription thus not suitable for sending events. Jabber Enhancement Proposals • Increase functionality via: • Message logging, jabber to email, HTTP-polling, HTTP-binding, service discovery, file transfer, etc. Publish Subscribe for Jabber (JEP-60). • Broadcasting of event notification for authorized subscribers.
PubSub Cont. • Server mediates connections. • Publishers send data to node • Servers can keep record of sent events • Affiliations to, subscribe, publish, purge items, config a node, delete a node. • Users can be publishers, subscribers, or blocked. • Message nodes can be discovered by clients. • subscription can be open, list, authorized. • Message nodes can be configured with persistent items, deletion, retraction, change notification.
PubSub Cont. • Errors • Stream errors (such as <xml-not-well-formed/>, <bad-format/>,<connection-timeout/><not-authorize/>, <remote-connection-failed>) handling in XMPP core (but errors within message xml possible. • Security • Core protocals include end-to-end signing and object encription via TLS and SSL. • Delays • Jabber servers can cope with thousands of concurrent users sending instant messages.
Problems using Jabber. • Few servers with PubSub support modules. • Only single commercial venture (PubSub.com). However, 200,000+ current users. • Few clients understand pubsub iq stanza messages (though messages are simple to handle). • JEP-60 still a draft after 2+ years (like most JEPs). • Aggregation?
VOTimeSeries Why do we need timeseries data for VOEvents? • Services like DataScope are fine for one-off events (GRBs, supernovae). • Recurring variable objects (QSOs, variables stars), microlensing events, etc, need timeseries to distinguish between real objects and artifacts (cosmic rays, ...). • Many large scale legacy timeseries datasets already exist (Macho, EROS, OGLE, Quest1, LONEOS, ROTSE, etc) but are either not available or are not being utilized. • Many more will come ... LSST, SM, Essence, Palomar-Quest, PannStars.