1 / 12

Transporting VOEvents

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.

gwyn
Download Presentation

Transporting VOEvents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Transporting VOEvents Andrew Drake, Matthew Graham, Roy Williams, et al.

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

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

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

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

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

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

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

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

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

More Related