sockets vs polling

gistfile1.md

Weekend Case Study: "Show PDF build logs in real time (like travis-ci) using web sockets"

Code: https://github.com/philschatz/pdf-ci Demo: http://pdf.oerpub.org

Motivation

1. PDf build log needs to be (eventually) persisted
2. client should see log messages as the build runs
3. client needs to download when a PDF is done

Attempt

• have separate socket for each PDF being built
• build slave emits messages, web server rebroadcasts them, and the browser would only listen to the build it cared about

Conclusions

Difficult to replay socket messages when disconnected (client may miss the "BUILD_COMPLETE" message)

Difficult to have separate socket URLs using socket.io (socket.io translates "URL's" to "Namespaces")

Listening to these Socket "URLs" requires registering all of them beforehand on the webserver

• Also, it is unclear how long after the build is complete that the webserver should stop listening

Persistence needs to be done by the build slave (not through web sockets)

Attempt 2

• Use rooms (which clients can .join(roomName) or .leave() and the webserver can .broadcast.to(roomName))

Conclusions

• requires using a common URL (can't even use a Namespace pseudo-"URL")
• requires defining custom join/leave messages

Did not implement.

Websockets

• Great at delivering intermediate messages

Not great for:

• persistent state change
• filtering messages to a set (>1) of interested parties.
• having custom URLs for different "chat rooms"

Polling

Some "Pros" for websockets:

1. quicker feedback
2. fewer bits sent on the wire

HEAD (instead of GET) and ETag reduces network overhead. Responses are only a couple bytes (addresses both points 1 and 2 above):

• 200 Done
• 202 Still working
• 401 Failed
• Not-Modified

Polling addresses the case of a build completing before a socket reconnects (you poll and see the final state).

Works with curl (easy 3rd-party dev and easy testing!). If there is a disconnect, still communicates the final state of the build.