Proposal for additions to Ethernet / EthernetUDP library

H

Headroom

Well-known member
I've posted in THIS thread a few days ago that I finished an overhaul of the EthernetBonjour library, removing all direct hardware calls to the W5100/W5200 Ethernet chip with calls from the EthernetUDP library.
These changes also necessitated the addition of a routine to the EthernetUDP library in order to allow sending UDP multicast messages, required to implement mDNS and DNS-SD. This has been very similarly discussed on the Arduino forum over a year ago in THIS thread.

EthernetUDP.h needs these lines aded in the sensible places:

Code: 
virtual uint8_t beginMulti(IPAddress, uint16_t);	// initialize, start listening on specified port. Returns 1 if successful, 0 if there are no sockets available to use Sending UDP packets
.
.
.
friend class EthernetBonjourClass;

EthernetUDP.cpp need this added routine:

Code: 
/* Start EthernetUDP socket, listening at local port PORT */
uint8_t EthernetUDP::beginMulti(IPAddress ip, uint16_t port) {

  for (int i = 0; i < MAX_SOCK_NUM; i++) {
    uint8_t s = W5100.readSnSR(i);
    if (s == SnSR::CLOSED || s == SnSR::FIN_WAIT) {
      _sock = i;
      break;
    }
  }

  if (_sock == MAX_SOCK_NUM)
    return 0;

  byte mac[] = {  0x01, 0x00, 0x5E, 0x00, 0x00, 0x00 };

  mac[3] = ip[1] & 0x7F;
  mac[4] = ip[2];
  mac[5] = ip[3];

//  byte mac[] = { 0x01, 0x00, 0x5e, 0x00, 0x00, 0xfb };

  W5100.writeSnDIPR(_sock, rawIPAddress(ip));
  W5100.writeSnDPORT(_sock, port);
  W5100.writeSnDHAR(_sock,mac);

  _remaining = 0;

  socket(_sock, SnMR::UDP, port, SnMR::MULTI);

  return 1;
}

I am proposing to add this permanently added to the Ethernet library in the Teensyduino distribution.

Crits and comments are welcome!
 
Project I did last year had this issue:
W5100 on my end, TCP connection to Microsoft Server OS on the other end, via cellular. Times 100.
When the TCP connection is disrupted (cellular issues aplenty) or if the socket is closed without the defined protcol, then Windows Server doesn't do its close for a long time. Like several minutes.
So you must use a different port number when re-opening the TCP connection. The prior port number is tied up until the MS server finally times out and closes.
For all connections for private messaging, I used a random port number between x and y, and seeded the random number generator with an environmentally dependent varying number.

This worsened when there's a firewall proxy as there often is for enterprise architectures.

Another cellular related issues is that WizNet doesn't implement dynamic/adaptive TCP windowing. If the ACK timeout is left to the default, and when the cellular round trip (packet then ACK response) - delay gets to 600mSec, which isn't uncommon for an oversubscribed cell site in busy times, then the TCP connection breaks. Frequently. Adaptive window sizing is an option in TCP. This isn't an issue when all the LANs and WANs are always "fast". I looked, and none of the other low cost NICs for embedded do adaptive window sizing.

Steve
 
Last edited:
Well understood. You've mentioned this issue in several other threads.
However, I fail to see how this addresses anything related to this thread.
 
stevech said:
I looked, and none of the other low cost NICs for embedded do adaptive window sizing.
Click to expand...

Even if they did, or it could be added in software, what does it matter if the TCP linger handing in Windows is still an intractable problem?

Or are you saying you plan to move to UDP? And if UDP is the answer, how does the UDP multicast API play into your idea? Why does multicast even matter at all, if your project involves communicating a stream of data back to a particular Windows server?
 
The abandoned TCP Connection just stays that way. I just open and new one and the server authenticates me and we press on, using a new port #.

I can't use UDP because firewall policy in most large companies prohibits incoming UDP. I wanted to use UDP to avoid the complications of keeping 100's of TCP connection up 24/7, for machine to machine telemetry that is time sensitive. But two large US auto manufacturers' IT people said no, they can't make a firewall exception for UDP, and would not consider port forwarding on their end, and so on. IT rules.

The TCP lingering problem - I solved by abandoning that port number and opening a new connection to the same MS Server on a new random port number excluding the one just abandoned. They may be a better way to deal with this, but I'm not that network smart and I could find no enterprise IT guy that understood this topic at the low level.

So the work-around did work out fine.

You can't ignore IT firewall policy and proxy policy, if you don't own both ends of the connection!
 
Steve, maybe this could be its own topic? Please?!

I really do want to support UDP multicast. Not as urgently as I want to release a stable Teensyduino in a few days, but I'm both interested in facilitating multicast projects and doing a couple myself (...when I have some time away from so much library development....)

Long-term, UDP multicast is important. Wandering off topic on TCP stuff isn't helping.
 
Sorry. I thought we were discussing the W5100 drivers and so on, not just UDP.

UDP broadcast or UDP multicast?
 
You must log in or register to reply here.
Back
Top