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

Hi Marcos,

> Another thing was the ability to manage multiple sockets in the same thread; the library should be singlethreaded - but not limited to one thread. So.. I never wanted to manage a fd_set for a select() call ever again, no more writing code for accepting a connection - this has already been done again and again in every single networking project ever made."

Of course current Raw Socket API does not have select() method. Methods to assign callback functions are defined instead.

> I agree. For that, we will really need a good use cases document and some communication with development communities that would be making use of these APIs (e.g., people making multiplayer games).  

Use cases have not been documented yet, but a few are mentioned in this public-sysapps mailing list; e.g. peer-to-peer applications, game servers[1], implementing existing protocols such as IMAP, SMTP, etc.[2]

Best regards,
Tomoyuki

[1] http://lists.w3.org/Archives/Public/public-sysapps/2013Jan/0055.html
[2] http://lists.w3.org/Archives/Public/public-sysapps/2012Oct/0040.html

On 2013/02/25, at 18:44, Marcos Caceres <w3c@marcosc.com> wrote:

> 
> 
> On Monday, 25 February 2013 at 09:19, Tomoyuki SHIMIZU wrote:
> 
>> 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.
> Ah, ok. I was not aware that that is where the design was derived from. I guess the good part of that is there is probably a lot of C++ APIs that have been build on top that simplify the functionality of sockets… or at least one would hope so, given that they were published in 1983.  
> 
> A quick search, shows that there is frustration with the POSIX design in the C++ community:
> http://www.alhem.net/Sockets/
> 
> "When making this library, there were a few things I wanted to achieve. I did not want to end up with C++ code that had to be used in the same way as the berkeley socket C API are being used ( connect/bind/accept - check result, write - check result, read - check result, etc, etc ). Another thing was the ability to manage multiple sockets in the same thread; the library should be singlethreaded - but not limited to one thread. So.. I never wanted to manage a fd_set for a select() call ever again, no more writing code for accepting a connection - this has already been done again and again in every single networking project ever made."
> 
> Here is another:
> http://sockets.carrierlabs.com/socket_cookbook.html
> 
> "This library is different from other socket libraries which define TCP sockets, UDP sockets, HTTP sockets, etc. The reason is the operations required for TCP, UDP, and RAW network communication is identical from a logical stand point. Thus a program could initially be written employing TCP streams, and then at some future point it could be discovered that UDP datagrams would satisify the solution. Changing between the two transport protocols would only require changing how the object is instantiated. The remaining code would in theory require minimal to no changes."
>> 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.
> 
> I agree. For that, we will really need a good use cases document and some communication with development communities that would be making use of these APIs (e.g., people making multiplayer games).  
> 
> 
>

Received on Monday, 25 February 2013 10:10:12 UTC