Comet (programming): Difference between revisions

Revision as of 13:23, 17 May 2018

Revision as of 07:54, 3 March 2019

Line 122:

Comet applications attempt to eliminate the limitations of the [[World Wide Web#How the Web works|page-by-page web model]] and traditional [[polling (computer science)|polling]] by offering two-way sustained interaction, using a persistent or long-lasting HTTP connection between the server and the client. Since browsers and proxies are not designed with server events in mind, several techniques to achieve this have been developed, each with different benefits and drawbacks. The biggest hurdle is the [[Hypertext Transfer Protocol|HTTP]] 1.1 specification, which states "this specification... encourages clients to be conservative when opening multiple connections".<ref>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, [http://tools.ietf.org/html/rfc7230#section-6.4 section 6.4]. IETF. Retrieved 2014-07-29</ref> Therefore, holding one connection open for real-time events has a negative impact on browser usability: the browser may be blocked from sending a new request while waiting for the results of a previous request, e.g., a series of images. This can be worked around by creating a distinct [[hostname]] for real-time information, which is an alias for the same physical server. This strategy is an application of ___domain sharding.

Specific methods of implementing Comet fall into two major categories: streaming and [[long polling]].

===Streaming===