UDP send data loss

[dogmaphobic]

This is related to #1696.

Is there a way to expose this to WiFiUdp.h?

https://github.com/esp8266/Arduino/blob/master/libraries/Ethernet/src/utility/socket.cpp#L409

That is, a way to check the status of the buffer before attempting to write?

From WiFiUdp, we don't have access to the underlying socket. If the socket was exposed, I could do something like:

WiFiUDP   udp;

<...>
udp setup and configured, etc.
<...>

uint16_t bufferFreeSize()
{
  uint16_t ret =0;
  SPI.beginTransaction(SPI_ETHERNET_SETTINGS);
    ret = W5100.getTXFreeSize(udp.socket());
  }
  SPI.endTransaction();
  return ret;
}

Thanks!

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[igrr]

As mentioned in #1696 (comment), the issue here is that underlying netif implementation doesn't return an error code when UDP packet gets lost. Also there is no API in Espressif SDK which would allow one to query the amount of space left in TX buffer chain. I'll see is we can add one though.

[dogmaphobic]

Also there is no API in Espressif SDK which would allow one to query the amount of space left in TX buffer chain

What about W5100.getTXFreeSize(udp.socket())?

I (think) I understand the restrictions of the Espressif SDK. Yes, getting access to the state of the actual socket buffer would be great but in the mean time, what about the above? When I call write() (in between a beginPacket() and endPacket()) I often get a return value, which is less than the amount of data I had requested to send. That's a result of a query to W5100.getTXFreeSize(udp.socket()) at a lower level. Knowing that free buffer size ahead of time would already help a lot. I can't split these messages and I can't wait around until the buffer is large enough again to continue.

Thanks!

[igrr]

I think you are looking at Ethernet library. W5100 is a chip which is used in Arduino Ethernet shield. It doesn't have anything to do with WiFi stack. This library supports a use case when you plug W5100 into ESP's SPI port and use it to make an Ethernet connection.

For WiFi, you need to look at WiFiUdp.cpp, UdpContext.h, and the underlying UDP implementation in LwIP stack, udp.c.

[dogmaphobic]

You're right. I had done a global search (all files) and bumped into that. I will have to go back and take a better look at it.

[devyte]

@d-a-v does this make sense in view of #3362 ?

[d-a-v]

In strict lwip point of view, it is not possible to know about remaining room in the output queue. udp stack sends packet through "netif->linkoutput()" which should returns whether the packet could be sent or not. This function is beyond lwip's scope, part of espressif physical layer api and we have no access to its buffers.

should because, as mentioned earlier in this thread, @igrr thinks it does not work. However, linkoutput()'s return value is checked in both lwip1.4 and lwip2. So a sketch is needed to try and overload udp's output and see if linklayer asks for pity at some point.

It has to be noted that even if an udp packet goes out, there is no mean to know if it is lost in the network before arriving to its destination.

In a network programming point of view, it is hardly necessary to know if there is room for udp output. If one need bandwidth control, there is tcp. Otherwise, a dialog with peer (to be able to know what is lost) is needed to make a sort of PID on bandwidth (nfs over udp did that, but they finally switched to tcp).

[devyte]

@d-a-v We can't do anything about what happens to an UDP packet in transit, UDP is not meant for that. However, if at all possible, we should at the very least make sure the packet actually gets sent, and do so without stepping on our own feet (i.e.: not rely on delays or w/e).
If there are any ideas on the table here, we should pursue them. I'll add this to the lwip2 project as well.

[d-a-v]

Currently the link layer (and the glue for lwip2) answer an lwIP's error code to the caller (ERR_OK or maybe something else but that could not be seen so far) so if an issue happens when sending the packet, udp..write() would return something different than requested packet length.
Closing as this issue is very old (milestones 2.3.0 up to 2.6.0) and happens to be not dependent on the core.