RE: [sysapps/raw socket api]:Proposal for resolution of remaining issues.

The socket resources on embedded devices (TV, tablets, smartphones) are limited. If there are hundreds of channels, and if hundreds of sockets are open, the concern is that the performance of device, and thus the user experience will be unpleasant.

There are many implementation choices, and we may want to keep the choices open. For example, implementation can open a certain number of sockets (depending on the device's limit), and each socket serves a certain number of channels, etc. Ultimately, the goal is to keep the desired user experience consistently across a variety of devices.

Thanks
Bin

From: Jonas Sicking [mailto:jonas@sicking.cc]
Sent: Tuesday, May 07, 2013 11:59 AM
To: HU, BIN
Cc: Nilsson, Claes1; public-sysapps@w3.org; Isberg, Anders; Edenbrandt, Anders; Isaksson, Björn
Subject: Re: [sysapps/raw socket api]:Proposal for resolution of remaining issues.

Does this mean that they have to use a single UDPSocket instance to listen to all those groups? Are there advantages to?
/ Jonas

On Tue, May 7, 2013 at 10:36 AM, HU, BIN <bh526r@att.com<mailto:bh526r@att.com>> wrote:
With regard to Issue 12 "Join/LeaveMulticastGroup", I think there are various commercial use cases we should consider. For example, commercial radio and TV services adopt multicast-addressable services, e.g. BBC Radio, Virgin Radio, and Telekom Austria, in receiving radio and TV broadcast. A user may want to listen to radio and watch TV from multiple providers, thus need the ability to join several multicast groups simultaneously, e.g. preview some other channels while watching one channel.

Just 2 my cents
Thanks

Bin

From: Nilsson, Claes1 [mailto:Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>]
Sent: Tuesday, May 07, 2013 8:08 AM
To: public-sysapps@w3.org<mailto:public-sysapps@w3.org>
Cc: Isberg, Anders; Edenbrandt, Anders; "Isaksson, Björn"
Subject: [sysapps/raw socket api]:Proposal for resolution of remaining issues.

Hi,

There are 7 open issues for the Raw Socket API.

I propose the following for each issue :

https://github.com/sysapps/raw-sockets/issues/11: Devices have more than one network interface. However, the issue is whether web applications should be able to select a specific local network interface to use for a socket or if always the "default interface"/the configured interface should be used. My view is that we should provide this possibility by an optional field in the constructor's options attribute. I must admit that I have difficulties in motivating this by tangible use cases but I haven't seen any existing TCP or UDP socket API that  does not provide the possibility to bind a socket to a local address. So there must be use cases and I propose that we keep this possibility in the specification. Objections?

https://github.com/sysapps/raw-sockets/issues/12: I propose a simplification here by removing the Join/LeaveMulticastGroup methods and instead adding the optional field "DOMString multicastGroupAddress" to dictionary UDPOptions. This means that if this field is present when the constructor is executed the UA will join the requested multicast group for the socket using for example IGMP. The UA leaves the multicast group when the UDP socket is closed through the close()  method. However, this assumes that there are no use cases for a socket to belong to several multicast groups simultaneously and/or for continuing to use a socket that previously was belonging to a multicast group. Do we have such use cases? If not I suggest that we use a field in dictionary UDPOptions to state multicast group instead of explicit methods. Objections?

https://github.com/sysapps/raw-sockets/issues/13: Any objection to adding "boolean addressReuse;" to TCPServerOptions dictionary?

https://github.com/sysapps/raw-sockets/issues/14: I have listed some basic use cases at http://www.w3.org/wiki/System_Applications_WG:_Raw_Sockets_API but each use case may need some elaboration. Any input, also including additional use cases, from the WG is appreciated.

https://github.com/sysapps/raw-sockets/issues/16: "Note that even if the socket is only sending to a multicast address, it is a good practice to explicitly join the multicast group (otherwise some routers may not relay packets)." This statement is based on input from 4D but I can't find any documentation that supports the statement. Could 4D or any other party provide any documentation supporting this statement?

https://github.com/sysapps/raw-sockets/issues/15: Just fix.

https://github.com/sysapps/raw-sockets/issues/10: Currently the options argument for TCP and TCPServer sockets just have a Boolean field "useSecureTransport;". This might be enough for a TCP client socket for server authentication using the default certificate and keys. If we need to support client authentication I guess that a client certificate has to be selected but I am not sure if this is something that should be exposed to the web application? For the secure TCP server sockets (if we should support that?) certificates and keys have to be provisioned but once again I am not sure what has to be exposed to web applications.
Ke-Fong has promised to provide input on secure sockets.

Comments?

Claes


Claes Nilsson M.Sc.E.E
Master Engineer - Web Research
Advanced Application Labs

Sony Mobile Communications
Tel: +46 705 56 68 78<tel:%2B46%20705%2056%2068%2078>
sonymobile.com<http://sonymobile.com/>

[SONY make.believe]