Comet (programming)

Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it.[1][2] Comet is an umbrella term, encompassing multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins. The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time.[3] The use of Comet techniques in web development predates the use of the word Comet as a neologism for the collective techniques. Comet is known by several other names, including Ajax Push,[4][5] Reverse Ajax,[6] Two-way-web,[7] HTTP Streaming,[7] and HTTP server push[8] among others.[9] Even if not yet known by that name, the very first Comet implementations date back to 2000,[18] with the Pushlets, Lightstreamer, and KnowNow projects.

EEML Microformats HTML WebSockets WebSocket is a protocol providing full-duplex communications channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C. Technical overview[edit] Browser implementation[edit] WebSocket protocol handshake[edit] To establish a WebSocket connection, the client sends a WebSocket handshake request, for which the server returns a WebSocket handshake response, as shown in the following example:[9]:section 1.2 Client request: GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Origin: Server response: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat Note that each line ends with an EOL (end of line) sequence, \r\n.

Web Service Architecture A Web service is a method of communications between two electronic devices over a network. It is a software function provided at a network address over the web with the service always on as in the concept of utility computing. The W3C defines a Web service as: a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.[1] The W3C also states: We can identify two major classes of Web services:REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of stateless operations; andArbitrary Web services, in which the service may expose an arbitrary set of operations.[2]

Constrained Application Protocol (CoAP) CoRE Working Group Z. Shelby Internet-Draft Sensinode Intended status: Standards Track K. Hartke Expires: December 30, 2013 C. Bormann Universitaet Bremen TZI June 28, 2013 Constrained Application Protocol (CoAP) draft-ietf-core-coap-18 Abstract The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. [include full document text]

JSON REST Representational State Transfer (REST) is a software architecture style consisting of guidelines and best practices for creating scalable web services.[1][2] REST is a coordinated set of constraints applied to the design of components in a distributed hypermedia system that can lead to a more performant and maintainable architecture.[3] REST has gained widespread acceptance across the Web[citation needed] as a simpler alternative to SOAP and WSDL-based Web services. RESTful systems typically, but not always, communicate over the Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT, DELETE, etc.) used by web browsers to retrieve web pages and send data to remote servers.[3] The REST architectural style was developed by W3C Technical Architecture Group (TAG) in parallel with HTTP 1.1, based on the existing design of HTTP 1.0.[4] The World Wide Web represents the largest implementation of a system conforming to the REST architectural style. Architectural properties[edit]

6LowApp The 6LowApp activity of the IETF coordinates work in the IETF to specify application (as well as possibly transport, security and operations) protocols for constrained nodes and networks, the Wireless Embedded Internet. 6LowApp is not itself an IETF Working Group, but is intended to result in the creation of IETF Working Groups. In the 6LowApp activity, definition of work will be carried out as well as initial work leading up to specifications. CoRE Working Group ¶ The first result of the 6lowapp activity has been the CoRE working group, which met for the first time at IETF77. Please see for more information about the CoRE WG. The CoRE Wiki is at — contributions are welcome. 6LowApp was kicked off in the BarBofs/IETF75/6LowApp "Bar BOF" at IETF 75 in Stockholm. At IETF76, 6LowApp had a quite successful BOF (in the IETF, this is a special meeting in the process of creating a working group).