TESTS/NETSOCKET: Refinement of netsocket tests

[betzw]

Description

Refinement of netsocket test socket_sigio

Status

READY

Migrations

NO

Deploy notes

A call to

`TCPSocket::recv(void *data, nsapi_size_t size)`

returns, following the mbed documentation, the number of received bytes on success, and a negative error code on failure.

So in case of success, the return value depends on both the value of parameter size but also on the amount of data already available. This means, that the value returned can be lower than or equal to the size of the data buffer passed as argument to the call.

Therefore, in the cases of test_tcp_hello_world() & find_substring() (i.e. test socket_sigio), the calls to TCPSocket::recv() might return from one byte up to sizeof(buffer) - 1 (i.e. 511) bytes for each single call, while the tests expect to receive the whole response string with a single call.

The commit applies a fix to this situation by implementing a receive loop which exits once there is no data anymore available to be read from the socket.

Notes:

cc @ashok-rao, @MarceloSalazar, @screamerbg

[ashok-rao]

@sarahmarshy , could you please check the changes? Thanks!

[kjbracey]

A TCP loop is indeed required. The end condition is ret being 0 (clean end of stream) or negative (error). You should probably fail outright if you see negative return, rather than just terminating the loop.

The set_timeout call is erroneous - in HTTP 1.0 you need to keep reading until end of stream or error, not until you just have no more data for now. Maybe you could have a long give-up timeout, but assuming all the data arrives immediately isn't right. If you've no timeout on the 1st read, there's no clear reason to have any timeout on subsequent reads.

I don't see what the UDP change is achieving. The test is expecting to receive exactly those sizes - those should be the sizes the server is sending, and the point of the test is really about stressing the network with that DTLS-handshake-like 5-packet burst and making sure all those 5 packets are received.

[kjbracey]

(In HTTP 1.1 you would terminate when you've received the correct number of total bytes - that would also be a possible TCP termination condition here).

To be clear on UDP sizes - it's a datagram protocol. The datagram size is part of the protocol. Datagram size is determined by the transmitter. If no datagrams are dropped (which is the point of the test), and the buffer is big enough for each datagram (which it is), the 5 sizes returned by recv() must exactly match the 5 sizes passed to send() at the transmit end.

[betzw]

From the mbed specs:

• nsapi_size_or_error_t UDPSocket::recvfrom(SocketAddress *address, void *data, nsapi_size_t size)
• nsapi_size_or_error_t TCPSocket::recv(void *data, nsapi_size_t size)

Do not see anything about that return of 0 means "clean end of stream" or about "datagram sizes".

[kjbracey]

That does look rather underspecified, but it's intended to be (a subset of) the standard BSD/POSIX socket interface. In the absence of any indication to the contrary, you should assume standard behaviour.

A TCPSocket that did not indicate end of stream or a UDPSocket that did not tell you how big datagrams were would be rather useless.

[kjbracey]

Relevant POSIX description here:

http://pubs.opengroup.org/onlinepubs/009695399/functions/recv.html

The recv() function shall return the length of the message written to the buffer pointed to by the buffer argument. For message-based sockets, such as SOCK_DGRAM [...], the entire message shall be read in a single operation. If a message is too long to fit in the supplied buffer [...] the excess bytes shall be discarded. For stream-based sockets, such as SOCK_STREAM, message boundaries shall be ignored. In this case, data shall be returned to the user as soon as it becomes available, and no data shall be discarded.

Upon successful completion, recv() shall return the length of the message in bytes. If no messages are available to be received and the peer has performed an orderly shutdown, recv() shall return 0. Otherwise, -1 shall be returned and errno set to indicate the error.

[betzw]

That does look rather underspecified, but it's intended to be (a subset of) the standard BSD/POSIX socket interface. In the absence of any indication to the contrary, you should assume standard behaviour.

A TCPSocket that did not indicate end of stream or a UDPSocket that did not tell you how big datagrams were would be rather useless.

Sorry, but I really do not think that arguing like this is permissible.

[betzw]

cc @nikapov-ST

[kjbracey]

I agree the documentation should be fleshed out - it's not sufficient to just assume those details of POSIX, no matter how fundamental they are to concept of the API.

Some other guys are busy formalising some of that assumed behaviour into stack tests - I'll prod them to make sure they also update the documentation for anything they're testing that isn't stated - can't really fairly fail people for things that aren't stated either directly or by reference. (@SeppoTakalo)

Is that the issue here - there is a (potential?) implementation that is losing datagram boundaries, so fails the "dtls handshake" test? If it fails this test for that reason, it would not support most applications.

We can't expect every stack to function exactly the same - they will have quirks, particularly in event signalling - but they at least have to be able to send and receive TCP and UDP data with the correct semantics, or you can't write correct applications.

[SeppoTakalo]

@betzw Thanks for pointing out the missing documentation.

I added little bit of clarification here: #5623

[betzw]

I have just removed the problematic modifications as contested by @kjbracey-arm.
Pls. give it a chance.

[kjbracey]

This is an worthwhile improvement - makes the test cope if data doesn't arrive in one recv call.

The test does have other existing issues, particularly that it uses blocking sockets with SIGIO, which is weird, but can't expect this PR to fix everything.

[kjbracey]

Don't need this if - len can't be negative if you're only adding positive numbers to it. (And if it could be negative here, I think find_substring would explode below anyway).

[betzw]

I think I have fixed the if(len >= 0) issue.

makes the test cope if data doesn't arrive in one recv call.

Regarding this, I would it expect to behave correctly considering what you said in one of your comments before about orderly shutdown and HTTP.

[kjbracey]

Yes, the code will now correctly pass any valid return sequence from recv, as far as I can see.

The remaining pre-existing issues are about spotting stuff that should really be failed, eg error return after receiving "Hello world", or trailing data. I'd also rather the sigio test didn't use blocking sockets - means it will just go straight into blocking state after first sigio.

But this PR doesn't need to deal with those.

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 715
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5604/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 368
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5604/

[mbed-ci]

Test : FAILURE

Build number : 544
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5604/544

[0xc0170]

Please review the latest tests results, related to this changeset

[mikaleppanen]

K64F runs out of event queue entries, since sigio calls get_data() several times while blocking for recv(). Updating event queue entries from 4 to 10 to test_socket_attach() should correct the issue:
EventQueue queue(10*EVENTS_EVENT_SIZE);

[betzw]

Suggestion applied in latest commit.

[0xc0170]

Thanks !
Is the last commit merge with upstream master ? Can you rebase instead please?

[kjbracey]

It would be a little more solid to ensure you never queue the event multiple times. Not sure if there's a way to do that built-in to the Event stuff? Feels like there should be. I've seen people use this sort of model manually:

void event_processor() {
     event_pending = false;
     // do work;
}

void irq_handler() {
    if (!event_pending) {
        event_pending = true;
        event.call(xxx);
    }
}

[betzw]

Is the last commit merge with upstream master ? Can you rebase instead please?

Should be.

It would be a little more solid to ensure you never queue the event multiple times. Not sure if there's a way to do that built-in to the Event stuff? Feels like there should be. I've seen people use this sort of model manually

Pls. feel free to adapt any solution you want ...

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1083
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5604/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 760
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5604/

[mbed-ci]

Test : SUCCESS

Build number : 890
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5604/890

[adbridge]

OK this one should not have gone in as it stood. The giveaway is the last commit :
d6cb385
Was a merge commit :
416 changed files with 154,614 additions and 2,707 deletions.
Should have been a rebase

[betzw]

The commit was of two commits: 8ec9f6b & d6cb385.
Hope this helps.

[adbridge]

The merge commit is so convoluted that it is not easily patchable to the release branch, thus this is being bumped out to 5.8.