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

Does keeping UDP sockets "open" really use any system resources?

/ Jonas


On Tue, May 7, 2013 at 12:12 PM, HU, BIN <bh526r@att.com> wrote:

>  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> 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]
> *Sent:* Tuesday, May 07, 2013 8:08 AM
> *To:* 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****
>
> sonymobile.com****
>
>  ****
>
> [image: SONY make.believe]****
>
>  ****
>
> ** **
>