Network/Notwork?

[Claus Reinke]

> Happy with my Winsock work-arounds for my small client-/server-test,
> I decided to try integrating the Network use into my target project, and
> got nothing but trouble. Again, things that work happily under Unix
> simply fail under windows.   [...]

Ok, sometimes I am a bit slow.. 
In my defense: misleading error messages can be a bit, well, misleading.

But first, for those who run into this via a search engine: the main error
turned out to be in my programming, not in the Network library, which 
works just fine (modulo the previously discussed fixes, and a couple of
smaller issues). I'll explain below in case you see the same effects.

Second, there are some smallish bugs in the Network and IO libraries.

    - in IO operations working on the result of socketToHandle, when 
      sockets are implemented using Winsock, error messages should consult
      WSAGetLastError (in my case, I kept getting "doesn't exist"-errors,
      where the real problem was WSAECONNRESET 10054 "Connection 
      reset by peer."). Note this is a separate issue from the "proper"
      socket operations consulting WSAGetLastError.

    - in Network.Socket: SocketOptions may include Linger, but 
      setSocketOptions uses packSocketOptions, which doesn't know
      about Linger? And shouldn't Linger be on by default for the 
      high-level Network lib?

Back to my little problem: what happened was that, in moving from
the test to the integration, I had made a little change (..), namely to move
from a single accept and a single loop in the server to several accepts
with separate loops. In fact, the motivation for all this is that I wanted
to have frequent calls to very lightweight and shortlived clients, using
the portable Network library to avoid having to use completely different 
mechanisms on the platforms we want to support.

Experienced Networkers will guess what happened: the clients sent
their request and terminated (the backchannel from the server to the 
application that calls the clients has to be implemented using another, 
though equally portable, mechanism). The server either read the request 
before the client closed the connection - or it didn't, resulting in a 
"connection reset by peer"-error when the server finally got around to 
try and read a request, and that error masqueraded as some different 
error (e.g., "doesn't exist") due to Winsock's error handling.

Workarounds: 
    - using hFlush does *not* seem to cure the problem??
    - using setSockOptions with Linger to control lingering of sockets with 
      pending data in response to close operations might be the "proper" way?
    - letting the short-lived connection partner wait for an acknowledgement
      from the longer-lived one helps me out in the meantime.

Sorry about the confusion. Once the fixes make it to the released versions,
the Network library is a nice asset. Perhaps a minimal tutorial, with a list of
traps to avoid, would be helpful - certainly more interesting than the old
quicksort example on haskell.org;-)

Claus

"experience is what you don't have until just after you need it" (source unknown)