Sockets bug?

Is this a Sockets bug? SockTest.zip is a socket demonstration. There are 2 programs client and server you run server in one taskwindow and client in another taskwindow – see the !readme file. When both are running what you type in either window is echoed in the other – the taskwindows can be on the same or different machines.

The problem is if I press escape in the server window the client window is correctly notified via socketread returning a size of 0 and stops. But if I escape in the client window the server window is not notified ie socketread doesn’t return 0 and so the server is not informed of the client closing.

Both client and server use the same code to read from the socket (terminal.c). I don’t see why it matters which window I press escape in the other should be notified shouldn’t it? Any thoughts?

I’ve not looked at your code (sitting in the garden enjoying the sun), but from memory the code to read data does not return whether or not the socket is connected – it can validly return zero bytes available. For my server I used a different call (recv?) to see if the socket is still connected prior to socketread to actually read data.
If this isn’t enough to get going with, let me know and I’ll post my method later on when I’m inside…

socketread is supposed to return 0 to indicate EOF when the remote socket closes – which is what happens if escape is pressed in the server window in my demo (the client window closes its socket because it receives the read size 0).

I’m trying to figure out why it works if I escape the server but not when I escape the client. I can only think its a bug.

That’s what the ROLtd documentation says…

How, pray-tell, does the socketread() call in non-blocking mode inform the client that there is no data available at this time? EWOULDBLOCK? That would be logical, but… it would appear to return zero as a valid number of bytes. I was dropping connections like crazy until I looked at what the sockets were doing instead of what the documentation said was supposed to happen.

Therefore, the code that I use is as follows:

static BOOL null_poll_handler(event_pollblock *event, void *reference)
{
   // ...a bunch of timeout handlers and stuff, not relevant, clipped out...

   // Is this connection still active?
   howmuch = recv(status.socket, &status.socketbuffer, 1, MSG_PEEK);
   if (howmuch == 0)
   {
      // Does NOT return zero bytes as a result. As we are non-blocking, it
      // would return -1 with errno set to 35 (EWOULDBLOCK).
      // Therefore, a result of zero means the other end has thrown in the
      // towel and the connection is finished. Life would be much simpler
      // if socketread() returned -1 and EBUGGEREDOFF or somesuch...
      finished = TRUE;
      return TRUE;
   }

   // Incoming data?
   howmuch = socketread(status.socket, &status.socketbuffer, SOCKBUFSIZE);
   if (howmuch > 0)
      ProcessInput(status.socketbuffer, howmuch); // deal with incoming

   return TRUE;
}

As I said earlier in the week, sockets aren’t particularly hard, just quirky and mildly annoying. ;-)

[I’ll await a metric tonne of people saying “argh! no! you can’t do that!”]

Thank goodness for that. It was a bug in my program. Line 42 of client.c should be

sock = socket(AF_INET, SOCK_STREAM, 0);

and not

int sock = socket(AF_INET, SOCK_STREAM, 0);

sock is a global so that it is closed atexit so it now works properly – pressing escape in either window closes the program in the other window. I’ve fixed the download if anyone wants to see how to write the simplest C program demostrating how to write a client and server I can think of.

Rick

It returns EWOULDBLOCK. FTPc uses this and the fact that a read of size = 0 means the other end has been closed and has never had problems. terminal.c shows in the download how I always read.

It returns EWOULDBLOCK. FTPc uses this and the fact that a read of size = 0 means the other end has been closed and has never had problems. terminal.c shows in the download how I always read.

Strange. I’ll need to look at my code again, as that isn’t what I recall seeing.
Thanks for the clarification of what should happen.