consider adding `status()` in EthernetClient

[JAndrassy]

Hello. I did a research on Arduino networking libraries and I noticed your EthernetClient class doesn't have a status() method. I think it is easy to implement it over LwIP.

https://github.com/JAndrassy/Arduino-Networking-API/blob/main/ArduinoNetAPILibs.md#client-getters-and-setters

btw: I maintain EthernetENC, the other library which doesn't have status() in EthernetClient. I plan to add it.

[ssilverman]

Thanks for doing this work. I think collected summaries like this are a good idea (that is, if they’re maintained).

Could you point me to a spec for EthernetClient::status()? This link doesn’t have the information.

I also noticed a few mistakes for my library. I’ll file some issues in your repo.

[JAndrassy]

other lwip based libraries return state from tcp_pcb from status. so it is enum tcp_state.
the Ethernet library returns values for constants with same name (most of them)

[ssilverman]

I was doing some digging, and found these links:

1. RFC9293 states
2. Diagram
3. w5100.h

The W5100 values are returned from that library’s client status() call. I noticed it has an extra INIT state and doesn’t have two FIN-WAIT states.

As I’m finishing this message, I noticed you responded; I haven’t read it yet.

[ssilverman]

other lwip based libraries return state from tcp_pcb from status. so it is enum tcp_state.
the Ethernet library returns values for constants with same name (most of them)

Do you plan on returning an enum or a uint8_t? In my opinion, an enum would be best. Could you point me to the enum definition you’re going to use? Or are you just defining your own with the 11 TCP states, and differing from w5100.h’s definition? i.e. removing INIT and adding a second FIN-WAIT?

[ssilverman]

I just filed this issue for corrections, changes, and additions: Networking-for-Arduino/Arduino-Networking-API#1

Thanks again for this work!

[ssilverman]

other lwip based libraries return state from tcp_pcb from status. so it is enum tcp_state.
the Ethernet library returns values for constants with same name (most of them)

Do you plan on returning an enum or a uint8_t? In my opinion, an enum would be best. Could you point me to the enum definition you’re going to use? Or are you just defining your own with the 11 TCP states, and differing from w5100.h’s definition? i.e. removing INIT and adding a second FIN-WAIT?

Oh, wait... I just realized you were referring to lwIP's internal enum.

[JAndrassy]

all libraries have `uint8_t' as return value.
I think the list of states from LwIP is the best choice. Many of the libraries are based on LwIP.
I don't expect the actual returned values to be the same in all llibraries, but constants with the same name should exist, so

  if (client.status() == ESTABLISHED) {

works

[ssilverman]

@JAndrassy Do you find that EthernetClient::status() is used much in the wild? Do you use it in your own projects? I'm just wondering how popular it is or would be.

[JAndrassy]

I don't use it because I didn't know before the research that almost all libraries have it.
status() tells the true state of the connection. connected() is still true if data are available for read. that is not good if you want to send data.
With accept() the sketch can/should manage the client object so I imagine more detail about the connection may be useful in some advanced use.

I have this in a project.

int modbusConnection() {
  while (modbus.read() != -1); // clean the buffer
  if (!modbus.connected()) {
    modbus.stop();
    if (!modbus.connect(symoAddress, 502))
      return MODBUS_CONNECT_ERROR;
    modbus.setTimeout(2000);
    msg.print(F(" MB_reconnect"));
  }
  return 0;
}

status() would be better than to have to read all the data that arrived late after my read function timeout out.

[ssilverman]

I agree that it could be useful for more advanced uses, for sure.

One thing about the Arduino ecosystem, in my opinion, is that there's lots of cargo culting, where simple momentum keeps APIs the way they are.

[JAndrassy]

simple momentum keeps APIs the way they are.

it looks like the API doesn't have an 'owner' at Arduino. That is why I try to start a community driven 'standardization' with an RFC process. But first I try to just extend the API for useful functions which already exist in many of the libraries so there is already a consensus.

[ssilverman]

I had added that function, by the way, just haven't pushed yet... I appreciate the suggestion and your efforts.

[ssilverman]

Added in ba0736d.