* Move IP Socket stuff to InternetSocket class which is inherited by TCP/UDP
* Implement sendto() and recvfrom() on TCP socket
* Implement connect() call on UDP
* Implement send() and recv() calls on UDP socket
Previously, send() was somewhat soft - it only ever made one send
call to the underlying stack, so it would typically take as much data
as would fit in the buffer, and only block if it was unable to write
anything.
This is not the intent of a POSIX socket/filehandle write. It should try
to send everything if blocking, and only send less if interrupted by a
signal:
- If the O_NONBLOCK flag is clear, write() shall block the calling
thread until the data can be accepted.
- If the O_NONBLOCK flag is set, write() shall not block the thread.
If some data can be written without blocking the thread, write()
shall write what it can and return the number of bytes written.
Otherwise, it shall return -1 and set errno to [EAGAIN].
This "send all" behaviour is of slightly limited usefulness in POSIX, as
you still usually have to worry about the interruption possibility:
- If write() is interrupted by a signal before it writes any data, it
shall return -1 with errno set to [EINTR].
- If write() is interrupted by a signal after it successfully writes
some data, it shall return the number of bytes written.
But as mbed OS does not have the possibility of signal interruption, if we
strengthen send to write everything, we can make applications' lives
easier - they can just do "send(large amount)" confident that it will
all go in one call (if no errors).
So, rework to make multiple sends to the underlying stack, blocking as
necessary, until all data is written.
This change does not apply to recv(), which is correct in only blocking until
some data is available:
- If O_NONBLOCK is set, read() shall return -1 and set errno to [EAGAIN].
- If O_NONBLOCK is clear, read() shall block the calling thread until some
data becomes available.
- The use of the O_NONBLOCK flag has no effect if there is some data
available.
Note, the registered callback is still disabled by a call to
socket_attach. This will avoid being called after the socket is closed
unless close is called from the attached callback, which is in irq
context.
As pointed out by kjbracey-arm, the previous behaviour was broken
for sockets that started out listening.
A few new error codes are added to nsapi_error_t and
support for non-blocking socket connect is added.
Nanostack's connect call will be non-blocking.
Whereas LWIP connect call is currently blocking, and it could be changed now
to be non-blocking.
It's currently possible to generate a socket event when a non-blocking socket is closed:
1. _pending is set to 0 in https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/TCPSocket.cpp#L22
when the socket is created.
2. close() calls event() in https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/Socket.cpp#L66
3. event() increments _pending, and since _pending is 1 it will call _callback() in https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/TCPSocket.cpp#L167
However, if send() (for example) is called, this can happen:
- send() is called and sets _pending to 0.
- when the data is sent, event() is called, which sets _pending to 1 and calls _callback().
- if close() is called at this point, there won't be an event generated for close() anymore,
since _pending will be set to 2.
Same thing for recv. Also, same thing for TCPServer and UDPSocket.
This PR changes the initial value of _pending to 1 instead of 0, so that
events are never generated for close().
nsapi_error_t - enum of errors or 0 for NSAPI_ERROR_OK
nsapi_size_t - unsigned size of data that could be sent
nsapi_size_or_error_t - either a non-negative size or negative error
Seppo Takalo
Kevin Bracey
Deepika
Bartek Szatkowski
Christopher Haster
Hasnain Virk
Bogdan Marinescu