1 Jul 2008 15:13
Some feedback on sockets programming using cegcc
I've just come to the end of doing some sockets programming using cegcc, and I thought some experiences might be useful to others. If you use blocking sockets, then things seem to work OK as far as I could tell using the newlib POSIX layer. But then, blocking sockets are not very exciting, and I wanted to use non-blocking sockets, which opens up more potential for weird behaviour. The first thing to note was that (the same as winsock) you really need to wait until the connection is complete before trying to do any send()'s or recv()'s. The reason (I think, from memory) is that if you rush to using send/recv after initiating the connection, then the error message you get when the socket is still connecting is indistinguishable from that you get when the socket has disconnected in error (ENOTCONN). On linux, for example, you get EAGAIN in this circumstance, which means you can get away with some simpler code in some circumstances. I'm not sure what the behaviour is on other POSIX systems, or what it is meant to be. The real showstopper to using "newlib sockets", though, was that the whole application would rudely exit if the connection was closed at the other end, and then you called send() on the socket. I wondered if this was due to send() ignoring MSG_NOSIGNAL, generating a SIGPIPE, and that the uncaught signal was causing a program exit. I did try writing a signal handler, which all compiled OK, but did not change the behaviour (and no evidence that the signal handler was called). I ran the application from the MSVC debugger and saw a "Data Abort" in the debugging window when the program exit occurred. I wonder if I had written my application as main program rather than a DLL (which is used(Continue reading)
RSS Feed