Nytro Posted December 12, 2014 Report Posted December 12, 2014 (edited) TCP and UDP Socket API W3C Working Draft 02 December 2014 This version:TCP and UDP Socket APILatest version:TCP and UDP Socket APIPrevious version:Raw Socket APILatest editor's draft:TCP and UDP Socket APIEditor:Claes Nilsson, Sony MobileRepository:We are on Github.File a bug.Commit history. Copyright © 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply. Abstract This API provides interfaces to raw UDP sockets, TCP Client sockets and TCP Server sockets. Status of This Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at All Standards and Drafts - W3C. The short name for this API has been changed from raw-sockets to tcp-udp-sockets as a more accurate description of its scope. This document was published by the System Applications Working Group as an updated Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-sysapps@w3.org (subscribe, archives). All feedback is welcome. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. This document is governed by the 14 October 2005 W3C Process Document. Note This specification is based the Streams API, [STREAMS]. Note that the Streams API is work in progress and any changes made to Streams may impact the TCP and UDP Socket API specification. However, it is the editor's ambition to continously update the TCP and UDP API specification to be aligned with the latest version the Streams API. Note This is a note on error handling. When using promises rejection reasons should always be instances of the ECMAScript Error type such as DOMException or the built in ECMAScript error types. See Promise rejection reasons. In the TCP and UDP Socket API the error names defined in WebIDL Exceptions are used. If additional error names are needed an update to Github WebIDL should be requested through a Pull Request. Note This is a note on data types of TCP and UDP to send and receive. In the previous version of this API the send() method accepted the following data types for the data to send: DOMString,Blob, ArrayBuffer or ArrayBufferView. This was aligned with the send() method for Web Sockets. In this Streams API based version only ArrayBuffer is accepted as type for data to send. The reason is that encoding issues in a Streams based API should instead be handled by a transform stream. Table of Contents1. Introduction 2. Conformance 3. Terminology 4. Security and privacy considerations 5. Interface UDPSocket5.1 Attributes 5.2 Methods [*]6. Interface TCPSocket6.1 Attributes 6.2 Methods [*]7. Interface TCPServerSocket7.1 Attributes 7.2 Methods [*]8. Dictionary UDPMessage8.1 Dictionary UDPMessage Members [*]9. Dictionary UDPOptions9.1 Dictionary UDPOptions Members [*]10. Dictionary TCPOptions10.1 Dictionary TCPOptions Members [*]11. Dictionary TCPServerOptions11.1 Dictionary TCPServerOptions Members [*]12. Enums 12.1 SocketReadyState [*]A. Acknowledgements [*]B. ReferencesB.1 Normative references Sursa: TCP and UDP Socket API Edited December 12, 2014 by Nytro 1 Quote
shaggi Posted December 12, 2014 Report Posted December 12, 2014 Mi se pare mie sau asta implica mai multe probleme de securitate decat solutii pentru problemele alea de vor sa le rezolve?Sunt de parere ca pentru a face ceva peer2peer, poti folosi o aplicatie pe care sa o ruleze userul pe pc personal, si sa comunice cu browserul prin websockets, si poti implementa aproape orice in browser. Quote