Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Websocket Messaging Patterns

Websocket Messaging Patterns

Eric Schoffstall

February 23, 2013
Tweet

More Decks by Eric Schoffstall

Other Decks in Programming

Transcript

  1. Me • I write full stack javascript • I work

    at Fractal • I like to code • I love open source
  2. Websocket? • Bidirectional • Always open • Less overhead than

    HTTP • Faster • Binary data • “Real-time web cloudscale 3.0”
  3. RPC History • Used to be a big deal for

    cross-process communication • REST/HTTP knocked it out of the game • WebSockets are bringing it back
  4. RPC – Use Cases • Scaling procedures horizontally • Replacement

    for REST over HTTP • Communicating between the client and server
  5. RPC – Example Sequence • Client sends request for procedure

    “hello” with arguments [“world”] • Server receives and unpacks message • Server calls procedure “hello” with arguments [“world”] • Server sends response with procedure return value • Client handles response
  6. PubSub • Client (subscriber) subscribes to a topic • Client

    (publisher) publishes a message about the topic without knowledge of subscribers • Similar to EventEmitter
  7. PubSub – Use Cases • Chat • Watching realtime changes

    – Whiteboards – File collaboration – Auction/trading systems
  8. PubSub – Example Sequence • Subscribers (Client A and B)

    subscribe to channel “test” • Publisher (Client C) publishes message “hey” to channel “test” • Client A and B receive message “hey” on channel “test”
  9. DSTM • Distributed Software Transactional Memory • Shared object between

    all clients • Changes to the shared object happen in “transactions” • Changes to the shared object are synchronized between all clients • Conflict resolution guarantees atomic transactions
  10. DSTM – Use Cases • Data synchronization • Distributed/scalable systems

    • Financial transactions • Anything where accuracy is involved
  11. DSTM – Example Sequence • Client A connects and receives

    object • Client B connects and receives object • Client B changes key “hello” to “world” • Client A changes key “hello” to “code camp” • Transaction from Client A is rejected due to conflict – synchronization is forced • Client A retries it’s transaction
  12. “Fat Client” - The Philosophy • Lower server requirements •

    Working offline • Higher server capacity • Scales easily • Uses less bandwidth
  13. “Fat Client” – Example Sequence • Client A receives index.html

    which then loads all static resources • If Client A needs something from the server it is either work or message passing which can be done over WebSockets • After the initial grab of static files everything is done via WebSockets