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

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


From: Nilsson, Claes1 []
Sent: Tuesday, May 07, 2013 8:08 AM
Cc: Isberg, Anders; Edenbrandt, Anders; "Isaksson, Björn"
Subject: [sysapps/raw socket api]:Proposal for resolution of remaining issues.


There are 7 open issues for the Raw Socket API.

I propose the following for each issue : 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? 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? Any objection to adding "boolean addressReuse;" to TCPServerOptions dictionary? I have listed some basic use cases at but each use case may need some elaboration. Any input, also including additional use cases, from the WG is appreciated. "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? Just fix. 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.



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

Sony Mobile Communications
Tel: +46 705 56 68 78<>

[SONY make.believe]

Received on Tuesday, 7 May 2013 17:37:32 UTC