Closed juhaylinen closed 6 years ago
Could you pls. specify which version of the driver you are using?
I have tested with driver versions 1.1.7 and 1.1.6, the result is the same.
Thanks for reporting this. Should be solved in next release of the driver, even if - in my eyes - from the API specs it is not 100% clear what the behavior should be when a reception is performed on a not yet connected socket. Do you know about a document which would clarify this?
Ciao @juhaylinen, I just have published a new version of the Wi-Fi driver, which should address your issue. If you have some time, it would be nice if you can give it a try.
API specs it is not 100% clear what the behavior should be when a reception is performed on a not yet connected socket.
UDP sockets are not connected.
So there is no defined order in which you need to call recvfrom()
or sendto()
After the socket is opened, it should just work.
You should be able to have UDP socket which you never read from. Only receive. Or you should be able to have socket which you never sendto. It is perfectly fine with the protocol, but not always fine with AT-command set which are mostly written only TCP in mind. I'm not sure if this is the case with IDW01
Ciao @SeppoTakalo,
sorry for having used with connected
the wrong term and such most likely created some confusion.
What I just wanted to point out is, that in the mbed API - actually I am referring to what is expressed by the doxygen comments of the respective methods/functions - it is/was not clear to me what the behavior of a call to recvfrom()
or recv()
should be when there has not yet been any call to sendto()
/connect()
on the same socket.
P.S.: pls. note that I am not talking about POSIX but only about what mbed specifies!
UDPSocket
does not have connect()
or recv()
calls. Those are in TCPSocket
I still cannot see how this causes confusion, there is no mention about any precondition that should happen before the call.
/** Send a packet over a UDP socket
*
* Sends data to the specified address. Returns the number of bytes
* sent from the buffer.
*
* By default, sendto blocks until data is sent. If socket is set to
* non-blocking or times out, NSAPI_ERROR_WOULD_BLOCK is returned
* immediately.
*
* @param address The SocketAddress of the remote host
* @param data Buffer of data to send to the host
* @param size Size of the buffer in bytes
* @return Number of sent bytes on success, negative error
* code on failure
*/
nsapi_size_or_error_t sendto(const SocketAddress &address,
const void *data, nsapi_size_t size);
/** Receive a datagram over a UDP socket
*
* Receives a datagram and stores the source address in address if address
* is not NULL. Returns the number of bytes written into the buffer. If the
* datagram is larger than the buffer, the excess data is silently discarded.
*
* By default, recvfrom blocks until a datagram is received. If socket is set to
* non-blocking or times out with no datagram, NSAPI_ERROR_WOULD_BLOCK
* is returned.
*
* @param address Destination for the source address or NULL
* @param data Destination buffer for datagram received from the host
* @param size Size of the buffer in bytes
* @return Number of received bytes on success, negative error
* code on failure
*/
nsapi_size_or_error_t recvfrom(SocketAddress *address,
void *data, nsapi_size_t size);
Only precondition that have ever been mentioned is this:
/** Create an uninitialized socket
*
* Must call open to initialize the socket on a network stack.
*/
UDPSocket();
So, as long as socket is opened, you can call sendto()
or recvfrom()
in any order you wish.
Also, knowing what POSIX defines helps, because we try to follow the same behaviour, even that the API is a bit different. That is the only acceptable standard covering Sockets (IEEE Std 1003.1).
After some testing, the issues seems to be resolved. Thanks for the fix.
I have a test that sends UDP packets to echo server and reads incoming packets back. Incoming packets are received in a separate thread.
When socket is set to blocking mode, it seems that recvfrom() call doesn't block and returns 0 several times before the packet is received. Similar behaviour is seen when socket is set to non-blocking mode. Instead of returning NSAPI_ERROR_WOULD_BLOCK, recvfrom() call returns 0 several times.
Board: NUCLEO_F401RE Shield: IDW01M1 Compiler: GCC_ARM
Steps to reproduce
Create
main.cpp
Build&Run.