Ethernet library: server connection without requiring data from client?

Projects Networking, Protocols, and Devices
1

I'm attempting to write a TCP server using the standard Arduino ethernet shield and library, and it's a bit frustrating since it isn't a web server. :expressionless:

Every example that I've found that is not a web server has this code:

  // wait for a new client:
  EthernetClient client = server.available();

  // when the client sends the first byte, say hello:
  if (client) {

What is the rationale behind requiring the client to send data before it can receive data? Makes no sense to me...

This problem has, of course, led me to the documentation, which is, ah, lacking. And confusing. (e.g.: why do I call a function called ethernetServer() in order to create a TCP/IP server? why are these things of type ethernetClient being allocated all over the place?) Likewise the code shows a significant lack of comments.

So, can anyone offer a clue as to how I can determine if the Wiznet device has set up a socket connection that I can service without requiring a data read?

-j

2

This TCP server example sketch does not require the client to send anything. It sends a "Hello" when the client connects. I use PuTTY in raw mode to use it.
http://playground.arduino.cc/Code/Telnet
It is slowed down so you have time to read the debug screen. Remove the delay(5000) from the loop to speed it up.

Is that what you are looking for?

3

At a glance that seems to be what I want; I'll have to do some testing and see.

I'd hoped to do it with the Ethernet API instead of digging down to the internals and hitting the Wiznet directly.

I'd planned for this to be a quick project; I hate to do it, but I may just kludge it up and make the client send something.

-j

4

If you can do with one persistent connection at a time, you can do that. But the ethernet library server code will only handle one persistent connection at a time. :frowning:

Mine will handle 4 simultaneous persistent connections on a w5100 and 8 on a w5200.

5

If you can do with one persistent connection at a time, you can do that.

How?

Specifically, how do I tell there's an established socket using the Ethernet library? (which is what you seem to be implying is possible, if I read correctly).

-j

6

Don't call client.stop(). Use "while(client.connected())".

7

SurferTim:
Don't call client.stop(). Use "while(client.connected())".

This doesn't really make sense - what about the initial connection, before I ever have a reason to call client.stop() ?

My code:

void setup() {
  Ethernet.begin(mac);

  listener.begin();

[...]

EthernetClient client;

void loop()
{
   if (client = listener.available())
    {
      delay(10);
      if (client.connected())
	{
           client.println("hello");
	  delay(10);
	  printWeather(client);
	  delay(50);
	  client.stop();
	}
    }

I get nothing until I send a character to the arduino, first time and every time.

-j

8

I get nothing until I send a character to the arduino, first time and every time.

That is correct. You must send something if you plan on using the ethernet library server code.

What happened to this approach?

I'd planned for this to be a quick project; I hate to do it, but I may just kludge it up and make the client send something.

9

What happened to this approach?

I hate kludges and I have little confidence software that requires kludges (in this case the Ethernet library). If I ask myself "why is this kludge necessary" all the possible answers are negative, to varying degrees.

Background: the project is environmental monitoring for labs and server rooms using nagios.

For the past few months I've been using a 10 minute hack involving UDP broadcasts from the arduino and an extra perl script that's a listener (running on a linux server) and injecting passive checks into the nagios queue. The nagios side of this quick and dirty hack is functional but undesirable (the correct way is to implement an active check script). The long term goal was to implement TCP on the arduino hardware and an active check script that talks to it directly.

I could leave the Arduino side running UDP broadcasts and write an active check script that waits for a broadcast instead of connecting and returning immediately, but bleh, that's just another kludge.

-j

10

If you have a Linux server, why not set up the Arduino as a client?

BTW, I like UDP. For speed, you can't beat it, especially if both devices are on the same localnet.

11

SurferTim:
If you have a Linux server, why not set up the Arduino as a client?

Because in general, the consumer (e.g. nagios server) should poll the sensor not the other way 'round. Also, having the sensor as the network server allows multiple clients (multiple nagios servers, etc) to poll the sensor.

Once some of my faculty found out about these sensors, they started making homework assignments that involve reading them - that's dozens of clients, sometimes per hour. UDP was no problem, we'll see if TCP holds up. probably not if the arduino is servicing one socket at a time and I have to do a blocking read before I get down to business.

BTW, I like UDP. For speed, you can't beat it, especially if both devices are on the same localnet.

I'm transferring about 75 or 80 bytes of text maybe twice a minute. Speed would not be an issue even if the network was a 9600 baud serial cable. :confused:

UDP speed comes at a cost, since there's no reliability built in to the transport. Being lazy, I like the fact that TCP handles error checking for me. My only check is "is TCP OK?"

I can't see speed being an issue in TCP vs UDP unless you've got some incredibly latency-sensitive applications, or some one-to-many high bandwidth applications. After all, the bits are flying down the same wire. You just lose 3+ overhead packets per session. Modern networks are full duplex, so the TCP ACKs aren't expensive in terms of bandwidth.

-j

12

Then if you are looking for a way to connect to the Arduino server and have it send something to the client without the client sending anything first, you are down to my telnet code above. I wish I had better news.

13

Oh well, sending/reading a character seems to be the simplest hack.

A quick and dirty test seems to indicate that, even though the Ethernet library only services one request at a time, it does not seem to drop connections. It seems to establish them, then service them after the currently open connection is closed.

thanks for the help.

-j

14

There is a very simple change you can make and/or add to the library code to avoid having the client need to send something.

EthernetClient EthernetServer::available()
{
accept();

for (int sock = 0; sock < MAX_SOCK_NUM; sock++) {
EthernetClient client(sock);
if (EthernetClass::_server_port[sock] == _port &&
(client.status() == SnSR::ESTABLISHED ||
client.status() == SnSR::CLOSE_WAIT)) {
if (client.available()) {
// XXX: don't always pick the lowest numbered socket.
return client;
}
}
}

return EthernetClient(MAX_SOCK_NUM);
}

See that call to "if (client.available())"?

That is where it checks for data from the client.

Don't do that check and you can just return the client reference.

Why anybody thought you needed to have data from the client to have a valid connection is beyond me.

A couple of things about the library I don't understand:

  • The constant creation/destruction of EthernetClient objects - doesn't seem terribly efficient BUT I'm not an experienced C++ programmer - maybe all the flailing is consider OK.

  • There are provisions for more then one client but no obvious to get at them.

I think this library good use a good overhaul.

15

The ethernet library is designed for the beginning or novice programmer as far as I can tell. You can access the w5100/w5200 library files if you require more functions. See replies #1 and #3.

Feel free to modify the library to suit your needs.