Difference between revisions of "About the Network Rail feeds"

From Open Rail Data Wiki
Jump to navigation Jump to search
(Remove speculation on firewalling, since there's a more plausible theory and I'm awaiting information anyway)
(Add actual information about the issue with STOMP and durable subscriptions)
Line 72: Line 72:
 
* '''Don't leave a failed client running''' - if you can connect but get an authentication or authorization error - '''stop your client''' - don't leave it continually trying.
 
* '''Don't leave a failed client running''' - if you can connect but get an authentication or authorization error - '''stop your client''' - don't leave it continually trying.
 
* '''Make sure your client handles failures''' - if your client fails to connect or is disconnected, use [http://en.wikipedia.org/wiki/Exponential_backoff an exponential backoff] and wait 1s, 2s, 4s, 8s, 16s etc. before trying to reconnect.  Service problems sometimes occur, and if everyone tries to reconnect every second, the service will not recover quickly.
 
* '''Make sure your client handles failures''' - if your client fails to connect or is disconnected, use [http://en.wikipedia.org/wiki/Exponential_backoff an exponential backoff] and wait 1s, 2s, 4s, 8s, 16s etc. before trying to reconnect.  Service problems sometimes occur, and if everyone tries to reconnect every second, the service will not recover quickly.
* '''Use a durable subscriber''' - if you want data to be queued in case you disconnect, request a [[Durable Subscription|durable subscription]] when you connect.
+
* '''Use a durable subscriber''' - if you want data to be queued in case you disconnect, request a [[Durable Subscription|durable subscription]] when you connect. See the note below if you intend to do this over STOMP.
* '''Use [http://stomp.github.io/stomp-specification-1.1.html#Heart-beating Stomp heartbeats]''' to detect network problems that may otherwise leave your client hanging with no data, or which could lead the server to consider your client still connected, and refuse to readmit your client ID.
+
* '''Use [http://stomp.github.io/stomp-specification-1.1.html#Heart-beating Stomp heartbeats]''' to detect network problems that may otherwise leave your client hanging with no data.
 +
 
 +
== Durable subscriptions via STOMP ==
 +
There's a bug in ActiveMQ, the software underlying the real-time Network Rail feeds, where it will occasionally fail to detect that the STOMP client associated with a durable subscription has disconnected, and on subsequent connection attempts with the same client ID, will issue an ERROR frame complaining about this, before hanging up. The firewall will then ban you from connecting to any service hosted on the same machine for several hours. There are two principal ways to avoid this:
 +
* Not using durable subscriptions (simply omit the client-id header entirely when connecting) - this risks losing some messages between reconnects
 +
* Connecting via the OpenWire protocol instead of via STOMP, where this bug doesn't appear to be present. If you prefer to use STOMP, or technical limitations require this, you can still achieve this by installing and configuring your own copy of ActiveMQ to connect and bridge these feeds, as detailed in [[Advanced Uses]].
  
 
==Examples==
 
==Examples==

Revision as of 22:23, 13 July 2022

Available Feeds

The following feeds are available from Network Rail:

Feed Type Rate Details
RTPPM Real-time 1 per minute Real Time Public Performance Measure. This shows the performance of trains against the timetable, measured as the percentage of trains arriving at destination on time, and is updated every minute
Train Movements Real-time Up to 600 per minute Messaging from the TRUST system, containing reports of train movements past timetabled calling and passing points.

Note: Messages are batched to reduce network overheads.

TD Real-time Up to 6000 per minute Berth-level data from the Train Describer system, showing raw data with train movements in more detail than the Train Movements feed.

Note: Messages are batched to reduce network overheads.

VSTP Real-time Low volume Late-notice train schedules which are not available through the SCHEDULE feed
TSR Updated Weekly Very low volume (11 per week) Temporary Speed Restriction data as published in the Weekly Operating Notice. Published at approx. 0600 UTC on Fridays
SCHEDULE Static Daily Extracts of train schedules from ITPS in JSON format
Reference Data Static Infrequent Reference data which can be used to help analyse other data feeds
Lift and Escalator API Dynamic Unknown Status of all lifts and escalators fitted with electronic monitoring units

How do I get the data?

First, register for an account by visiting http://datafeeds.networkrail.co.uk. You will receive a confirmation email. Follow the instructions to log in and change your password. When your account is active, you can connect to the service. Your account may be in one of three states - the system will send you an email when your account is activated and able to access feeds.

Once you have logged in to the system, the My Feeds tab lists all of the data feeds available. You must select the topics that you wish to access. This can be done by highlighting them in the Available column and clicking the right arrow icon to move them to the Selected column. Once you have selected your chosen feeds, click the Update Subscription button. You will then be able to access those feeds.

Accessing the data feeds

The real-time feeds are accessed using Stomp - details are on the Network Rail connection details page.

The static feeds are available via authenticated HTTP GET requests.

Good Practice

Please bear in mind the following points when you use the service - they're here to make sure everyone gets a good service:

  • Sign up with one account - it gives an accurate reflection of how many people are actually using the service.
  • Connect to the service once - you can receive multiple feeds in a single connection. If you need to access the data more than once, you can do so - but be sensible!
  • Don't leave a failed client running - if you can connect but get an authentication or authorization error - stop your client - don't leave it continually trying.
  • Make sure your client handles failures - if your client fails to connect or is disconnected, use an exponential backoff and wait 1s, 2s, 4s, 8s, 16s etc. before trying to reconnect. Service problems sometimes occur, and if everyone tries to reconnect every second, the service will not recover quickly.
  • Use a durable subscriber - if you want data to be queued in case you disconnect, request a durable subscription when you connect. See the note below if you intend to do this over STOMP.
  • Use Stomp heartbeats to detect network problems that may otherwise leave your client hanging with no data.

Durable subscriptions via STOMP

There's a bug in ActiveMQ, the software underlying the real-time Network Rail feeds, where it will occasionally fail to detect that the STOMP client associated with a durable subscription has disconnected, and on subsequent connection attempts with the same client ID, will issue an ERROR frame complaining about this, before hanging up. The firewall will then ban you from connecting to any service hosted on the same machine for several hours. There are two principal ways to avoid this:

  • Not using durable subscriptions (simply omit the client-id header entirely when connecting) - this risks losing some messages between reconnects
  • Connecting via the OpenWire protocol instead of via STOMP, where this bug doesn't appear to be present. If you prefer to use STOMP, or technical limitations require this, you can still achieve this by installing and configuring your own copy of ActiveMQ to connect and bridge these feeds, as detailed in Advanced Uses.

Examples

Code examples for various languages are available from the Example Code page.

The advanced usage page contains examples of some advanced applications for the data feeds, including bridging the ActiveMQ feeds to your own messaging server.

Support

If you are having problems with the feeds:

  • First, read this wiki - there's a lot of material here that will help you
  • Check the FAQ to see if you have a common issue
  • Check twitter to see if an issue has been reported
  • If you want to discuss your problem with other people working with the service, the openraildata-talk group on Google Groups will be useful
  • Finally, if you're still having a problem, email dsg_nrod.support@caci.co.uk

Releases

For further information on the content of releases please see the release notes.


Network Rail Open Data Feeds
Data Feeds About the Feeds Account States Durable Subscriptions Example Code ( PHP / C# / Java / Ruby / Node.js) • Advanced UsesFAQ Release Notes
RTPPM RTPPM Feed
Train Movements Train Movements Feed Train Activation Train Cancellation Train Movement Train Reinstatement Change of Origin Change of Identity Change of Location TSPEED Field Planned Cancellations Cancellation Codes
TD TD Feed C-Class Messages S-Class Messages Train Describers TD Berths
VSTP VSTP Feed
TSR TSR Feed Route Codes
SCHEDULE SCHEDULE Feed Schedule and Location Records Association Records CIF Codes How Scheduling Works Allowances
Reference Data Reference Data Feed TOC Codes CIF Codes Delay Attribution Codes Identifying Locations (STANOX, TIPLOC, NLC and 3-Alpha Codes) STANOX Geographical Areas Train Planning data