Re: [sysapps/raw socket api]: Status on outstanding issues and proposal to close a number of issues.

On Thu, Jun 27, 2013 at 8:47 AM, Nilsson, Claes1 <
Claes1.Nilsson@sonymobile.com> wrote:

> **
>
> *Error handling to be revised, *
> https://github.com/sysapps/raw-sockets/issues/18:****
>
> I have made a number of changes that address this issue. See
> https://github.com/sysapps/raw-sockets/pull/23. *Can I close the issue?*
>

I think the defined error handling in at least a few cases still need to be
improved. I looked through the error handling for TCP, but I expect that
some of these comments apply to UDP as well.

When setting up a new connection, there should be machine readable errors
indicating is the failure was due to lack of network access, the port
already being taken, the receiving side refusing the connection, etc. Right
now the page just seems to receive a human readable string describing the
type of error which makes it hard for an application to do error handling.

I suggest we use separate errors here rather than the generic
"NetworkError". Alternatively subclass DOMError and add another property
which contains an enum describing the exact type of error.


I suspect the same applies for the case when an already established
connection is dropped.


The constructor algorithm requires the implementation to synchronously know
if this application is already using the requested port/address combo, and
then throw an error. This is problematic if different windows of the
application are run in different processes since it requires blocking IPC.
Additionally it means that the error "address/port combo already in use" is
delivered in two different ways depending on if the combo is used by this
application or another application.


Step 2 in the "send" algorithm is both wrong and not needed. When the wrong
type of data is passed we should throw a TypeError rather than
InvalidAccessError. However this isn't needed to be spelled out since it's
already covered by the WebIDL spec. You also don't need to spell out that
an exception should be thrown if no argument is passed for example.


What does step 3 in the "send" algorithm mean by "data is too long to pass
atomically through the underlying protocol"? The underlying protocol here
is TCP, does that mean that attempting to send() anything that doesn't fit
in a single TCP packet should cause the connection to be dropped? I would
have expected the data to be divided into several TCP packets automatically.

In the same step, I think it's a problem that we change the readystate to
"closed" synchronously. That means that if the following code:
socket.send(arraybuffer1);
socket.send(arraybuffer2);
is unsafe. Since the first call to .send() could cause the readystate to
synchronously change, the second call could throw an exception. Instead I
think we should queue a task which does all of the substeps of step 3
(which removes the need for any of the substeps to queue tasks).


I wonder if we should use "NetworkError" to indicate out-of-memory errors
like the ones in step 1 of "Upon a new TCP message being received" and step
3 of the send algorithm. None of the exceptions in the DOM Core spec seems
to fit the bill though...

/ Jonas