1.2.2 WebSocket Transport

ETP is designed to use the WebSocket protocol for transport. A full description of WebSocket is beyond the scope of this document. In brief, WebSocket is a protocol, standardized by the Internet Engineering Task Force (IETF) as RFC 6455 (http://tools.ietf.org/html/rfc6455), which allows for high-speed, full-duplex, binary communication between agents (primarily Web servers and browsers) using TCP and the standard HTTP(s) ports 80/443. This approach allows communications to easily and safely cross many corporate firewalls. Like WebSocket itself, ETP communication is strictly between two parties, with no allowance for multi-cast messages.

ETP is bound to WebSocket in two main ways:

• ETP is considered a subprotocol of WebSocket as defined in sections 1.9 and 11.5 of RFC 6455.

• ETP messages map directly to the “payload data” section of WebSocket frames and messages. In most cases, these details are invisible to developers, because developers use a vendor-supplied library to interface with WebSocket.

All ETP communication is carried out through the asynchronous exchange of messages. This approach is distinct from the request/response pattern normally associated with HTTP, and the “RPC style” associated with many SOAP implementations, including all WITSML versions before v2.0. Of course, many use cases still require a request on the part of one agent and expect a response of some sort from the other; however, implementers should always consider these things to be happening asynchronously and handle processing using state machines that model the various timings of message exchange that could occur.

The WebSocket protocol guarantees the delivery of messages in the same order that they were dispatched. To ensure messages are correlated correctly, ETP uses several mechanisms, which include:

• All messages within a session are numbered. Message numbers are integers and MUST be unique within a session.
• A correlationId is included in each message, which may designate a given message as being part of a ‘response’ to a previous request.
• Large messages may be sent in parts, with a mechanism in the message header for determining when the last part arrived.

• Various ETP subprotocols may impose specific ordering and numbering of certain messages.

These mechanisms are described in more detail below.