How do stock market data feeds work?

Question

or any other type of realtime data feed from server to client... I'm talking about a bunch of realtime data from server to client. i.e., an informational update every second.

Does the server magically push the data to the client, or does the client need to continuously poll the server for updates? And under what protocol does this usually work? (http, socket communication, etc?)

Syncopation

All of these are possibilities. You can probably check the code depending on which one you are curious about... – Hairy

google for "comet", "reverse ajax", and "long polling". – Hispania

"Every second" :)... a second is eternity when trading at large – Martamartaban

Answer 1

In server-side financial applications used by brokers/banks etc. market data (quotes,trades etc) is transmitted over TCP via some application-level protocol which most probably won't be HTTP. Of course, there's no polling. Client is establishing TCP connection with server, server pushes data to client. One of common approaches to distribute market data is FIX. Thomson-Reuters have bunch of cryptic proprietary protocols dating from mainframe days to distribute such data.

HTTP can be used for SOAP/RESTful to transmit/request data of not-so-large volume, like business news.

UPDATE Actually, even FIX is not enough in some cases, as it has big overhead because of it's "text" nature. Most brokers and exchanges transmit high-volume streams, such as quotes, using binary-format protocols (FAST or some proprietary).

Backman

Answer 2

In a simple case:

1. Create a server with a listening socket.
2. On the client, connect to the server's socket.
3. Have the client do a while(data = recv(socket)) (pseudocode)
4. When the server has something exciting to tell the client, it simply send(...)s on the socket.

You can even implement this pattern over HTTP (there is no real upper time limit to an HTTP socket). The server need not even read from the socket - it can be trying to write to the firehose only.

Usually a TCP socket is employed - messages arrive in order, and are best-effort. If latency is more important and dropped or out of order is not an issue, UDP can be used.

Amphibiotic

i don't think this would work over http, doesn't an http session close after a certain amount of time? it would have to be a permanent session.. so from what I'm getting here you're basically saying tcp/socket – Syncopation

@foreyez: HTTP doesn't not specify a socket close time. And HTTP is over a socket, just with a defined protocol within it. – Amphibiotic