Websockets is a technology that provides bi-directional, full duplex commu-nication over a single TCP socket. TCP is built for long-lived flows, so with HTTP the more connections, the shorter flows we have. TCP congestion con-trol doesn’t have time to ramp up. Using the Websocket connection for long lived application-to-application scenarios can be advantageuous (not only) for this reason.
Websockets are designed to be implemented in web browsers and web servers. One of the goals is to avoid long polling connections between clients and server which have a negative impact on browser usability and bandwidth usage. Relevant specifications today are:
• The WebSocket API [43]: Draft defines the interface for working with WebSockets in web browsers. The access to basic functionality is pro-vided via JavaScript.
• The WebSocket Protocol [30] (RFC6455): Standard proposal defines the lightweight wire protocol on top of TCP and the initial upgrade process from a HTTP-based handshake. This specification includes ref-erences to various registries at the Internet Assigned Numbers Author-ity (IANA), combined under the WebSocket Protocol Registries [51]. A short history of protocol is outlined in table 2.2.
Websockets have the advantage of using a single TCP socket for the bi-directional communication. The protocol is defined in the application layer, and it can be used to overcome restrictions applied to the transport layer. The
Table 2.2: History of The Websocket protocol
date document-name comment
1 January 2009
draft-hixie-thewebsocketprotocol-00
First draft from Ian Hickson.
6 May 2010
draft-hixie-thewebsocketprotocol-76
Latest Hixie-draft.
23 May 2010
draft-ietf-hybi-thewebsocketprotocol-00
First HyBi-draft.
11 January 2011
draft-ietf-hybi-thewebsocketprotocol-04
Resolved severe pro-tocol vulnerability.
30 September 2011
draft-ietf-hybi-thewebsocketprotocol-17
Latest HyBi-draft.
12 December 2011 RFC6455 Proposed standard.
Websocket protocol features a HTTP-compatible handshake and therefore the traffic generated is similar to the one generated through HTTP. It traverses firewalls, proxies, and routers seamlessly and leverages Cross-Origin Resource Sharing (CORS). The communication channel can be protected against eaves-dropping with TLS, much like HTTPS. The default ports are 80 or 443, such that enterprises are not required to open additional ports in their firewalls.
The initial handshake is done via HTTP(s). Afterwards the connection is “up-graded” and the TCP connection remains open as WebSocket channel, where the lightweight WebSocket protocol takes over. Heartbeat is needed otherwise it gets disconnected after 300s by default.
Sub-Protocols are application-level extensions that define how the payload must look like. WebSockets can be used as transport layer for any protocol.
Status codes according to RFC6455 [30] and IANA WebSocket Close Code Number Registry [51]:
• 1000 Normal closure; the connection successfully completed whatever purpose for which it was created.
• 1001 The endpoint is going away, either because of a server failure or because the browser is navigating away from the page that opened the connection.
• 1002 The endpoint is terminating the connection due to a protocol error.
• 1003 The connection is being terminated because the endpoint received data of a type it cannot accept (for example, a text-only endpoint received binary data).
• 1004 The endpoint is terminating the connection because a data frame was received that is too large.
Websocket in-band closing handshakeTCP closing handshake
TCP endpoint TCP endpoint
TCP ACK TCP ACK TCP FIN
TCP FIN
Websocket close frame
Websocket close frame
Websocket close status codes
0000 - 999 Reserved and not used
1000-2999 - Reserved for Websocket protocol 3000-3999 - Reserved for libraries & applications 4000-4999 - Reserved for private use
Figure 2.6: In-band WebSocket closing handshake before TCP connection terminates
• 1005 Reserved. Indicates that no status code was provided even though one was expected.
• 1006 Reserved. Used to indicate that a connection was closed abnormally (that is, with no close frame being sent) when a status code is expected.
• 1007 The endpoint is terminating the connection because it has received data within a message that was not consistent with the type of the mes-sage.
• 1008 The endpoint is terminating the connection because it has received a message that violates its policy. This is a generic status code.
• 1009 The endpoint is terminating the connection because it has received a message that is too big for it to process.
• 1010 The endpoint (client) is terminating the connection because it has expected the server to negotiate one or more extension, but the server didn’t return them in the response message of the WebSocket handshake.
• 1011 Internal error. The server is terminating the connection because it encountered an unexpected condition that prevented it from fulfilling the request.
• 1015 TLS handshake error.
. Sensor web
Scientists have long understood the importance of quality time series observa-tions for conducting research and analyzing data. There is a growing demand for visual analysis provided by web-based client/server systems and even on mobile devices. Web accessible sensor networks of all types (flood gauges, air pollution monitors, stress gauges on bridges, mobile hearth monitors) and archived sensor data that can be discovered, accessed and, when applicable, controlled using open standard protocols and interfaces (APIs).
The Geospatial Consortium (OGC) has successfully introduced various standards for web-services dealing with spatial data, among which the most prominent are the Web Feature Service (WFS) and the Web Map Service (WMS).
OGC SWE standards [8] enable web-based discovery, exchange and pro-cessing of sensor observations, as well as tasking of sensors systems. The mod-els, encodings, and services of the SWE architecture enable implementation of interoperable and scalable service-oriented networks of heterogeneous sen-sor systems and client applications. Wildfires, river basins, tsunami alerts, and environmental risk management are just some of the uses of OGC’s interoper-ability framework for Web-based access and control of sensors and sensor data.
SWE standards are being harmonized with other OGC standards for geospa-tial processing. The vision is to define and approve the standards foundation for “plug-and-play” Web-based sensor networks. The functionality includes:
• Discovery of sensor systems, observations, and observation processes that meet an application or users immediate needs.
• Determination of sensor’s capabilities and quality measurements.
• Access to sensor parameters that automatically allow software to process and geolocate observations
• Retreival of real-time or time-series observations and coverages in stan-dard encodings.
OGC SWE includes the following pending OpenGIS® Specifications:
1. Observations & Measurements Schema (O&M) – Standard models and XML Schema for encoding observations and measurements from a sen-sor, both archived and real-time.
2. Sensor Model Language (SensorML) – Standard models and XML Schema for describing sensors systems and processes; provides informa-tion needed for discovery of sensors, locainforma-tion of sensor observainforma-tions, pro-cessing of low-level sensor observations, and listing of taskable proper-ties.
3. Transducer Markup Language (TransducerML or TML) – The concep-tual model and XML Schema for describing transducers and supporting real-time streaming of data to and from sensor systems.
4. Sensor Observations Service (SOS) [69, 70]- Standard web service in-terface for requesting, filtering, and retrieving observations and sensor system information. This is the intermediary between a client and an ob-servation repository or near real-time sensor channel.
5. Sensor Planning Service (SPS) – Standard web service interface for re-questing user-driven acquisitions and observations. This is the interme-diary between a client and a sensor collection management environment.
6. Sensor Alert Service (SAS) [68]– Standard web service interface for pub-lishing and subscribing to alerts from sensors.
7. Web Notification Services (WNS) – Standard web service interface for asynchronous delivery of messages or alerts from SAS and SPS web ser-vices and other elements of service workflows.
The goal of OGC SWE SOS is to provide access to observations from sensors and sensor systems in a standard way that is consistent for all sensor systems in-cluding remote, in-situ, fixed and mobile sensors. SOS standard version 1.0.0 [69] is describing the messaging system based on SensorML and TML encod-ing which invoke requests on HTTP server in REST or POX architecture style.
SOS standard version 2.0 [70] provide binding over SOAP webservice.
The key to the model on Figure2.7is that an Observation is modeled as an event which produces a result whose value is an estimate of a property of the observation target or feature of interest. An observation instance is classified by its eventTime, featureOfInterest, observedProperty, and the procedure used (often a Sensor). Note that OGC SWE SOS is not based on EDA architecture but on SOA service.
. Previous and related work
In previous work [47] we developed Websocket server Draft 76 and HTML5 client application that was sending the words to the server via Websocket and XHR and server analyzed them by morpohological analyzer. Result of anal-ysis was returned to the client. Benchmark of XHR vs. Websocket tunnel shows up to 1:180 RTT reduction for dataset with 10000 words. Today many of Websocket server implementation exists.
Ruottu and Markus created a proof-of-concept called Browser-Socket [74] that utilized WebSockets for browser-to-browser (peer-to-peer within browsers) communication. They have developed a Firefox plug-in that created a socket server.
Figure 2.7: Basic Observation structure
Table 2.3: Table of Websocket servers (servers without RFC6455 not men-tioned)
Server, version Language Version date SuperWebSocket 0.8 C#.Net Jun 4, 2013
Alchemy 2.2.1.238 C#.Net May 31, 2012 Eclipse Jetty Server 9.0.4 Java Jun 26, 2013
Tornado 3.1 Python Jun 15, 2013 Pywebsocket 0.7.9 Python May 18, 2013
Ratchet 0.2.7 Python Jun 23, 2013 sgcWebSockets 2.4 Delphi Jun 24, 2013
clws Lisp Not released yet.
Some guys at LearnBoost did an evaluation on “Socket.IO and firewall soft-ware” [41]. They have investigated 16 personal firewalls to find out how they treat WebSocket connections. Three of them blocked WebSocket connections.
For the remaining firewalls there was always a fall-back port available. Inter-estingly, some browsers were blocked even on port 80. They concluded that a move of the WebSocket traffic to port 443 fixed all connection problems.
. Informal description of Weda architectural style
. Motivation
Weda architectural style is hybrid architectural style that we have derived from other network-based styles, such as web services [39] and HTML5 web-sockets [30] to get practical real-time SOA 2.0 [59] solution for WWW. It provides uni-form connector interface to the client and server implementers allowing them to extend their existing web services (SOAP 1.2, REST, POX) with new type of endpoints and binding while keeping their HTTP server endpoints to legacy clients alongside with Weda endpoints. When such an architectural style im-plemented into API, users can get World-Wide-Web messaging and workflow orchestration ESB platform. Such a solution can improve scalability of WWW and SOA and can change interaction habits and user experience extensively.
An ontology is a data model that represents a set of concepts within a do-main and the relationships among those concepts. The semantics of WWW-based architecture ontology is defined as follows [33], [72]:
EAType⊆ Infrastructure(t) ∪ Management(t) ∪ Process(t)∪
Configuration(t)∪ Component ∪ Connector ∪ Port ∪ Role ∪ QA (3.1) in which, EAType denotes enterprise architecture type, for example Weda. Ta-ble 3.1 lists architectural ontology entities – infrastructure, management, ser-vice, service consumer and data – constrained in their relationships in order to achieve a desired set of architectural properties. It was chosen because unlike component-based approach which was used to describe a REST architectural style [32] it has ability to model dynamic behaviors.
Figure3.1 gives a high-level process view of Weda infrastructure and man-agement, while details are described in next sections.
Schema indicates number of application clients connecting to server host process as usual in client-server style. Server host process runs in standard web server, such as Apache, IIS or it can be console app as well. Figure shows how you can combine existing standards with new parts of stack, allowing the vendors to reuse their code.
At the top part of the schema new parts of infrastructure are highlighted by a wider line. Other chapters explain their details.
Table 3.1: Weda’s major architectural ontology entities Ontology
entity
Details Example
Infrastructure Service provider, Origin server, server host process
Apache httpd, IIS, web infra-structure
Management Service host, Weda gate-way, set of endpoints and channels traversable through firewalls and reverse proxies.
Weda transport binding, Weda client and server API, websocket connec-tion, session manager, weda channel,Event processor with Esper engine.
Service Object representing a set of operations for the client, IO data, message exchange patterns, tem-porarily available thru the set of endpoints to a service. In Weda there are infrastructure specific ser-vice, OGC SOS serser-vice, Weda’s event processing layer
Data Service contract and callback contracts, Weda messages
WSDL 2.0, Weda sub-protocol, SOAP encod-ing, XML, MTOM
Service con-sumer
Proxy stub Application client, user agent , event source or event sink
Process Discovery, Choreography Uddi
application client server host process
service host
"legacy 2" service instance per call service host
application client session B
session manager session A
EDA manager service proxies
weda endpoint, session B
service host callback service proxy instance
service proxy instance
"legacy" service proxy instance
application business layer
pox endpoint
soap endpoint
"legacy" service instance per session
"legacy" service proxy instance application client
some async service proxies service proxy instance callback service proxy instance
async service instance per session
Event processing Services (CEP)
callback contract
"legacy 2" service instance per call
"legacy 2" service instance per call
"legacy 2" service instance per call
"legacy 2" service instance per call
"legacy 2" service instance per call
BL
Figure 3.1: High-level process view of Weda infrastructure
At the bottom we have a very standard web service host, which is run-time environment that creates and controls web-service’s context and instance life-time and makes it active. Inside service host there is one “legacy” service, in-stantiated per call, so a new service object is created and destroyed by each HTTP request and response. This allows using the service instance by HTTP channel, because state is not maintained between the calls giving us a stateless web service. Stateless web services should have light-weight initialization code (or none at all) that can be called from a single threaded model.
Service instance must be initialized to expose (service related) entry points for a service called endpoints (address, binding, contract). Special constraints are made to endpoints in Weda architectural style to cooperate well with trans-port channel and Weda gateway as outlined in chapter3.3.3. On the service-consumer side there are proxy stubs generated from the WSDL file. There are special options for client proxy objects and some constraints too as outlined in chapter3.5.