Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Multiplexing in WebSockets

No description

David Colblin

on 18 November 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Multiplexing in WebSockets


Node.js & PHP
Multiplexing in WebSocket
Building a Multiplexing Module
Module Demo ClickRace
The Web before today
The Problem & Multiplexing
Aim & Objectives
The Web Before Today
The Problem & Multiplexing
Aim & Objectives
Existing tools & our Custom tool
Results & Conclusion
Module as a framework layer
Code Division Multiplexing
Live Example
Benchmarking & Conclusion
Live Example of a network game
Node.js & PHP
Existing & our Custom Benchmarking
Results & Conclusion
Code Division Multiplexing
Module as a framework layer
Live Example
Benchmarking & Conclusion
Presented By
David Moutoussamy

Request/Response Model
No structure for the future web
Today's need for live experience: faster and yet cheaper messages
Came in HTML5 Specification
Young technology but fast growing
Bidirectional & Cheap communication
Subscribe/Publish replaces Request/Response
Network restrictions due to legacy
Frameworks attempts to solve: Sock.js & Socket.IO
Create a multiplexing module for WebSocket frameworks
Open Source, JavaScript-based server
Scalable, one thread, all users managed in one event loop
High performance server for WebSocket
Node.js is still new, requires improvement
Community sees into it a 'new PHP'
Highly scalable server, can be used as a Push server, i.e, alongside PHP
Library runs on Node.js
Provides a large number of events
Fallback mechanism to polling
Easy to code; uses namespaces structure
Has multiplex feature
Socket.IO was too heavy and cluttered, so Sock.js library was made to solve this
Also based on Node.js server
Still fresh framework but already adopted in various projects and platforms
Strong support, compared to Socket.IO
Has multiplex feature
PHP based WebSocket library, no need for Node.js (additional server)
Good support, widely used as it is easy for newcomers in WebSocket
Large number of events
Tools exist to measure WebSocket Performance but no tool to measure multiplexing
We therefore require to create a custom benchmarking script
What will be measured : layers of Sock.js & Socket.IO
How to measure/proceed
Measured Socket.IO against Sock.js; the only two multiplexing frameworks
Figures and conclusion
Three sources on same page
Communicates to one server
But different recipients
Results processed by respective recipients
Cats will meow
Dogs will bark
Birds will tweet
Crashed over 100 simultaneous sources
Apache (on modest server) does not scale well, compared to Node.js
CDM slows down de/multiplexing layers
Benchmark results of the new module
Test existing frameworks
Benchmark frameworks with multiplexing
Build module from results conclusions
Test and implement it in an application
Ratchet will be used. Flexible PHP-based WebSocket framework.
Multiplexor & Demultiplexor layers: module implementation will be done at both sides.
One Channel to be created from the several sources
Code Division Multiplexing (CDM) as a method for multiplexing
A ClickRace game based on module
Connect to the server on your WebSocket compliant browser
Choose your player
Click bar to race
Press 'A','S' and 'D' to wheelie
How to proceed & timestamp container
10, 100, 500, 700, 1000 sources
Sources will open & close once
2 messages per source/receipt
Container/Array of size 4
Average is collected at browser
Figures: Sock.js & Socket.IO
Client Sent:
Process (client)

Client Received:

Multipx (client) + Network + Demultipx (server)

Server Sent:

Process (server)

Server Received:

Multpx (server) + Network + Demultipx (client)


The huge difference is created at the client received time. Where Sock.js is the best at. Demultiplexing at server is done much faster where demultiplexing at client was heavy.
Source sends message, message is collected by multiplexor.
Multiplexor 'signs' the message w.r.t. to its sender, sends to server.
Demultiplexor reads and finds the signature
Redirects the message to the corresponding receipt w.r.t. to signature.
Same is done at both client and server side.
Source A sends "
Message becomes "
Benchmarking of new module
Max steady limit on Apache is 100 sources
Ratchet Mx shows twice delay
Multiplexing layer at server is cluttered; CDM does too much string manipulation in memory.
Must note that 100 sources can be enough for a moderate application, but Apache will still be under stress
Require more coding hours to be efficient, but Apache is a limit at itself.
Full transcript