If socket.Available is called on a UDP socket, the CC3100 socket's IOCTL (FIONREAD) function does an implicit recv(...) function call, pulling in all available data that will fit in the internal buffer, and then returns the total # of bytes in the buffer as the response to FIONREAD (i.e. bytes available count).
This seems appropriate for TCP, but UDP should really only be reading datagrams--and not concatenating datagrams into a buffer. With UDP datagrams, if we are going to pull in data to a buffer here we should pull in data only if there is no data in the buffer already (so that datagrams don't get concatenated), and we should use recvfrom(...) to capture the remote endpoint as well--in case the user calls recvfrom(...) instead of recv(...) to capture the data.
Also: if recv(...) and recvfrom(...) behave differently when the socket is bound (or is not bound) then we must take that into consideration and may need to adjust the behavior mentioned in the previous paragraph.
Finally, we should also modify recv(...) to return the receive buffer (but _not more additional data) if the socket is UDP instead of TCP...and we should also modify recvfrom(...) to retrieve data from the buffer (instead of calling recvfrom(...) if the buffer is not empty.
And before we do any of that...we should see how .NET normally behaves with UDP sockets when socket.Available is called followed by socket.RecvFrom(...).
After all that: make sure that the main Netduino.IP stack behaves consistently and correctly for UDP sockets with .Available and .Receive/.ReceiveFrom as well.
If socket.Available is called on a UDP socket, the CC3100 socket's IOCTL (FIONREAD) function does an implicit recv(...) function call, pulling in all available data that will fit in the internal buffer, and then returns the total # of bytes in the buffer as the response to FIONREAD (i.e. bytes available count).
This seems appropriate for TCP, but UDP should really only be reading datagrams--and not concatenating datagrams into a buffer. With UDP datagrams, if we are going to pull in data to a buffer here we should pull in data only if there is no data in the buffer already (so that datagrams don't get concatenated), and we should use recvfrom(...) to capture the remote endpoint as well--in case the user calls recvfrom(...) instead of recv(...) to capture the data.
Also: if recv(...) and recvfrom(...) behave differently when the socket is bound (or is not bound) then we must take that into consideration and may need to adjust the behavior mentioned in the previous paragraph.
Finally, we should also modify recv(...) to return the receive buffer (but _not more additional data) if the socket is UDP instead of TCP...and we should also modify recvfrom(...) to retrieve data from the buffer (instead of calling recvfrom(...) if the buffer is not empty.
And before we do any of that...we should see how .NET normally behaves with UDP sockets when socket.Available is called followed by socket.RecvFrom(...).
After all that: make sure that the main Netduino.IP stack behaves consistently and correctly for UDP sockets with .Available and .Receive/.ReceiveFrom as well.