Re: Sockets, was Re: [Raw Socket API]. New version separating UDP and TCP interfaces

Hi Marcos,

I agree on avoiding deviation from other W3C standards such as WebSocket API.

At first glance, current Raw Socket API (based on Chrome Socket API) seems to be derived from traditional Berkeley/POSIX socket APIs[1] widely used by C/C++ developers. It would be better to make APIs easy to understand for developers who are familiar with POSIX socket, however, simpler API would be much helpful for many web developers.

Best regards,
Tomoyuki

[1] http://en.wikipedia.org/wiki/Berkeley_sockets#Socket_API_functions


On 2013/02/23, at 0:06, Marcos Caceres <w3c@marcosc.com> wrote:

> Hi, 
> I don't yet have concrete feedback on this API, but from first glance I'm concerned that it seems to deviate quite a bit from Web Sockets (I understand that it has to, because of the different requirements of the protocols). Also, the Node.js community has done a lot of work in creating socket APIs that seem much simpler than the ones proposed (at least it seems so at first glance), such as:
> 
> * http://socket.io/
> * https://github.com/LearnBoost/engine.io
> * https://github.com/socketstream/ss-sockjs
> * https://github.com/nodejitsu/nssocket/
> * https://github.com/socketstream/socketstream
> 
> See also "npm search socket"
> 
> It would be great if we could do a round of collecting data about what APIs are out there, and what developers are using and critically evaluate those. It would suck to reinvent the wheel when there are already good patterns out there that pair client and servers nicely (like socket.io does with its client-side library). 
> 
> Better still, we should reach out to the developers of the above libraries to review and comment on anything we come up with.
> 
> Also, where are the use cases for the raw socket APIs documented?  
> 
> -- 
> Marcos Caceres
> http://datadriven.com.au
> 
> 
> On Friday, 22 February 2013 at 01:21, Tomoyuki SHIMIZU wrote:
> 
>> Hi Claes,
>> 
>> Thanks again for your further update!
>> 
>>> [Claes] Yes, that is correct. I will remove the peerAddress and peerPort attributes from AcceptInfo as they are attributes of the newly created socket object for the accepted socket:
>> 
>> Thanks!
>> 
>>> Furthermore I see that the type for the socket attribute should be TCPSocket, not RawSocket.
>> 
>> Right.
>> 
>>>> * As for ReadInfo, RecvFromInfo and AcceptInfo, I would like to know
>>>> how developers can check local address and port actually receiving from
>>>> or connecting with the peer in the callbacks. If using
>>>> 'this.localAddress' for example, I'm afraid that applying bind()[2]
>>>> could prevent the callback functions from checking them.
>>> 
>>> 
>>> [Claes] I am not sure that I follow your concern here. The intention is that a successfull bind() will set the values of localAddress and localPort attributes and a successful connect() will set the values of peerAddress and peerPort attributes and accept() will set the values of all attributes. Will the application not be able to access the socket object attributes? If for example the created socket object is "myTCPSocket" wouldn't myTCPSocket.localAddress work? However, the Chrome socket API, http://developer.chrome.com/apps/socket.html, uses a method getInfo() to retrieve attributes of the socket object. Do we need something similar here?
>> 
>> 
>> Sorry for my confusing comment. I intended NOT bind() in Raw Socket API, but Function.prototype.bind() in JavaScript 1.8.5 and later (ECMAScript 5)[1], which can manually assign another object to 'this'. (Note: This issue would not be a problem when callback functions refer to global variables.)
>> 
>> Best regards,
>> Tomoyuki
>> 
>> [1] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Function/bind
>> 
>> 
>> (2013/02/21 18:22), Nilsson, Claes1 wrote:
>>> Hi again Tomoyuki and thanks for your further comments!
>>> 
>>> See my replies inline below.
>>> 
>>> Best regards
>>> Claes
>>> 
>>>> -----Original Message-----
>>>> From: Tomoyuki SHIMIZU [mailto:tomoyuki.labs@gmail.com]
>>>> Sent: den 19 februari 2013 02:27
>>>> To: public-sysapps@w3.org (mailto:public-sysapps@w3.org)
>>>> Subject: Re: [Raw Socket API]. New version separating UDP and TCP
>>>> interfaces
>>>> 
>>>> Hi Claes,
>>>> 
>>>> Thanks for your update.
>>>> 
>>>>> */[Claes] The reason for the current design is that I used the Chrome
>>>> Socket API as starting point but of course I could change the structure
>>>> to be more consistent with other API proposals to SysApps or other W3C
>>>> APIs that uses event handlers if this provides value. However, due to
>>>> the current discussion on DOMRequest I suggest that currently no change
>>>> should be done until we have a resolution on the structure of SysAps
>>>> APIs/*.
>>>> 
>>>> Agreed. I have the same concern about that discussion.
>>>> 
>>>> AFAIW DOMRequest and DOMFuture are newly proposed for upcoming specs
>>>> (could be related to DOM4 or later). On the other hand,
>>>> addEventListener (DOM 2 Event) and on- event handlers (before DOM 2)
>>>> are current or older standards[1], widely used in many current web apps.
>>>> IMO, for developers' benefit, older, current and newer styles of event
>>>> handler could coexist, however, they should be dependent on SysApps'
>>>> resolution.
>>>> 
>>>>> I think it is useful that addresses and port numbers of source and
>>>> destination would be attributes of RawSocket. Such a RawSocket could
>>>> make parameter definitions of callback functions simpler.
>>>>> 
>>>>> */[Claes] This information has now been added as attributes of the
>>>> RawSocket interface./*
>>>> 
>>>> Thanks a lot. Additional comments below:
>>>> 
>>>> * In AcceptInfo for example, peerAddress and peerPort seem to be
>>>> equilavent to socket.peerAddress and socket.peerPort, respectively,
>>>> aren't they?
>>> 
>>> 
>>> [Claes] Yes, that is correct. I will remove the peerAddress and peerPort attributes from AcceptInfo as they are attributes of the newly created socket object for the accepted socket: Furthermore I see that the type for the socket attribute should be TCPSocket, not RawSocket.
>>>> 
>>>> * As for ReadInfo, RecvFromInfo and AcceptInfo, I would like to know
>>>> how developers can check local address and port actually receiving from
>>>> or connecting with the peer in the callbacks. If using
>>>> 'this.localAddress' for example, I'm afraid that applying bind()[2]
>>>> could prevent the callback functions from checking them.
>>> 
>>> 
>>> [Claes] I am not sure that I follow your concern here. The intention is that a successfull bind() will set the values of localAddress and localPort attributes and a successful connect() will set the values of peerAddress and peerPort attributes and accept() will set the values of all attributes. Will the application not be able to access the socket object attributes? If for example the created socket object is "myTCPSocket" wouldn't myTCPSocket.localAddress work? However, the Chrome socket API, http://developer.chrome.com/apps/socket.html, uses a method getInfo() to retrieve attributes of the socket object. Do we need something similar here?
>>>> 
>>>> Best regards,
>>>> Tomoyuki
>>>> 
>>>> [1] https://developer.mozilla.org/en-
>>>> US/docs/DOM/element.addEventListener#Older_way_to_register_event_listen
>>>> ers
>>>> [2] https://developer.mozilla.org/en-
>>>> US/docs/JavaScript/Reference/Global_Objects/Function/bind
>>>> 
>>>> 
>>>> (2013/02/18 19:29), Nilsson, Claes1 wrote:
>>>>> I have uploaded a new version,
>>>> 
>>>> 
>>>> http://sysapps.github.com/sysapps/proposals/raw-socket/Socket.HTML ,
>>>> based on comments from Michal Mocny and Tomoyuki SHIMIZU. Thanks for
>>>> your support!
>>>>> 
>>>>> Michal:
>>>>> 
>>>>> * Since you switch to constructor usage (great!) why not have two
>>>> types: TcpSocket and UdpSocket, so that the methods that only apply to
>>>> one type are not defined? Also, the constructor RawSocket('tcp') seems
>>>> less nice than just TcpSocket().
>>>>> 
>>>>> */[Claes] I now have a base RawSocket interface with attributes and
>>>> methods that are common to UDP and TCP and UDPSocket/TCPSocket
>>>> interfaces inheriting from RawSocket that adds methods specific for UDP
>>>> and TCP./*
>>>>> 
>>>>> * close() replacing disconnect/destroy: The state of the RawSocket
>>>> after construction but before connect is different than the state after
>>>> a close() call. Also, it is not clear if close() should be called with
>>>> udp sockets that don't issue a connect(). I think that combining the
>>>> concept of disconnect/destroy should be well thought out first.
>>>>> 
>>>>> */[Claes] I have changed the name of the method to destroy() as after
>>>> this operation the socket cannot be used again. Regarding udp sockets
>>>> that don't issue a connect() the intention is that they should be
>>>> destroyed as well as all resources related to the socket are released.
>>>> This means that destroy() both executes connect() and destroy. However,
>>>> if there are use case for doing disconnect() without destroy() I have
>>>> to revisit this./*
>>>>> 
>>>>> * recvFrom: if you do not support buffer size, the developer will
>>>> have to do their own buffer management. The callback does not need to
>>>> be called with each datagram received, the payload may be buffered or
>>>> sliced up.
>>>>> 
>>>>> */[Claes] I haven't changed this yet. Could we have buffer size
>>>> optional or nullable meaning that if not provided or null then callback
>>>> is issued at each received datagram? If buffer size is provided the
>>>> received datagrams are buffered or sliced up and the callback is issued
>>>> when buffer size is reached or when nothing more is received (how to
>>>> detect that?) For both situations I assume that recvFrom must be called
>>>> again to continue receiving after a callback.
>>>>> How does the Chrome socket API work here? Do you have a use case for
>>>> 
>>>> 
>>>> using buffer size?/*
>>>>> 
>>>>> *//*
>>>>> 
>>>>> Tomoyuki:
>>>>> 
>>>>> on- style event handlers such as onconnect(), onrecvfrom(), etc.
>>>> would be easier to understand and use for many web developers.
>>>>> 
>>>>> Corresponding event definitions, which can be used in
>>>> addEventListener() etc., would be useful, too.
>>>>> 
>>>>> */[Claes] The reason for the current design is that I used the Chrome
>>>> Socket API as starting point but of course I could change the structure
>>>> to be more consistent with other API proposals to SysApps or other W3C
>>>> APIs that uses event handlers if this provides value. However, due to
>>>> the current discussion on DOMRequest I suggest that currently no change
>>>> should be done until we have a resolution on the structure of SysAps
>>>> APIs/*.
>>>>> 
>>>>> I think it is useful that addresses and port numbers of source and
>>>> destination would be attributes of RawSocket. Such a RawSocket could
>>>> make parameter definitions of callback functions simpler.
>>>>> 
>>>>> */[Claes] This information has now been added as attributes of the
>>>> RawSocket interface./*
>>>>> 
>>>>> *//*
>>>>> 
>>>>> Best regards
>>>>> 
>>>>> Claes*//*
>>>>> 
>>>>> *//*
>>>>> 
>>>>> *//*
>>>>> 
>>>>> *//*
>>>>> 
>>>>> cid:3333625383_1036728
>>>>> 
>>>>> *Claes Nilsson M.Sc.E.E*
>>>>> Master Engineer, Research
>>>>> Technology Research - Advanced Application Lab
>>>>> *
>>>>> Sony Mobile Communications*
>>>>> Phone: +46 10 80 15178
>>>>> Mobile: +46 705 56 68 78
>>>>> Switchboard: +46 10 80 00000
>>>>> E-Mail:***mailto:claes1.nilsson@sonymobile.com*
>>>> 
>>>> 
>>>> <mailto:claes1.nilsson@sonyericsson.com>
>>>>> Visiting Address; Nya Vattentornet
>>>>> SE-221 88 LUND,
>>>>> Sweden
>>>>> 
>>>>> *Disclaimer:
>>>>> *The information in this e-mail is confidential and may be legally
>>>> 
>>>> 
>>>> privileged. It is intended solely for the named recipient(s) and access
>>>> to this e-mail by anyone else is unauthorized. The views are those of
>>>> the sender and not necessarily the views of Sony Ericsson and Sony
>>>> Ericsson accepts no responsibility or liability whatsoever or howsoever
>>>> arising in connection with this e-mail.Any attachment(s) to this
>>>> message has been checked for viruses, but please rely on your own virus
>>>> checker and procedures. If you contact us by e-mail, we will store your
>>>> name and address to facilitate communications. If you are not the
>>>> intended recipient, please inform the sender by replying this
>>>> transmission and delete the e-mail and any copies of it without
>>>> disclosing it.
>>>> 
>>> 
>> 
> 
> 
> 
>

Received on Monday, 25 February 2013 09:20:34 UTC