http://cpp.tribe.net/thread/065cf463-a37c-430d-9ffc-abb48704a7c1?format=rss Tribe.net. Local Connections http://CPP.tribe.net/thread/065cf463-a37c-430d-9ffc-abb48704a7c1#eacb8512-7879-43bb-970b-e295dae9b60c Sounds all basically correct to me. select() success does not neccessarily mean the socket is ready to recv() only something "interesting" happened.Only if there are no errors on the socket can you assume there is data to recv(). I don't know what recv() would return but 0 seems likely if there was an error. Otherwise, recv() returning 0 means the socket was closed, which unless you closed your own socket would mean it was closed on the other end. The 0 is returned from the low level network layer and not by the app running on the other end. It might also mean that socket was reused on the other end to connect somewhere else. This is the same in blocking or non-blocking. You should only get a 0 bytes on an error from a closed connection. -1 & EWOULBLOCK should be the norm. EWOULDBLOCK is what you should get when you are done reading from the socket. i.e. call recv() and build the data stream until you get EWOULDBLOCK which means that only way you're getting more data is if you stall and wait until more is sent. The only other time you can legitimately get EWOULDBLOCK is if you are somehow out of buffers. This could only happen if your buffers weren't enough to cover the load you are putting on them. This can happen if you call send() too often that there isn't room in the buffers for it because the other stuff hasn't made it on the wire yet or your buffers are full of data from sockets you haven't called recv() on yet. And if you are using connectionless sockets your buffers could be filled by dead clients who haven't got the message you don't want to talk to them any more I'm assuming you are using select() because of a high number of sockets to scan from a server type app. Hope that helps a bit. I'm not able to Tribe as frequently as I have been with my current load. That 0 recv sound familiar. If your in control of both ends I'd double check the other end didn't think it timed out or do a close or bind its socket somewhere else. Worst case there's always Ethereal. Mon, 30 Oct 2006 22:18:36 GMT http://CPP.tribe.net/thread/065cf463-a37c-430d-9ffc-abb48704a7c1#eacb8512-7879-43bb-970b-e295dae9b60c Hypno 2006-10-30T22:18:36Z http://CPP.tribe.net/thread/065cf463-a37c-430d-9ffc-abb48704a7c1#9886d0f0-de26-4c10-87f3-2042b4a6d850 Hello, all ... Like many of us i'm sure, i've done my share of sockets (either BSD or WinSock) code. It's usually not so hard. I'm chasing a bug right now, though, which has got me wondering about some questions that I thought I knew: Does recv() _only_ return 0 if the server closed the connection? Does setting the socket as blocking or non-blocking matter change this at all? Does select() work differently on non-blocking vs. blocking sockets? My understanding is this: 1. If select() sets the FD / socket in the input set, it's ready to be read. 2. If recv() is called on the FD after select() sets it, and it returns a positive #, that # is the # of bytes read from the socket. 3. If recv() is called on the FD after select() sets it, and recv() returns 0, the server closed the connection. 4. If recv() is called on the FD after select() sets it, and recv() returns -1, an error occured ... if errno / WSAGetLastError() is set to EAGAIN / WSAEWOULDBLOCK, then the server is still there, it has just not sent anything yet. This should only happen if the FD / socket is set to non-blocking mode (otherwise recv() will block). Is my understanding flawed? I'm seeing recv() return 0 (blocking and non-blocking) very often (i'm sending an HTTP request to Apache to get a block of data e.g. a range request, and if recv() returns 0 only if the server disconnected, then it's disconnecting very often before it sends the entire range I requested). This behavior varies by time of day, file requested, etc. which suggests that Apache is loaded and dropping me, but others stress that it doesn't do that, or at least, not anywhere near as often as I seem to be seeing. I would expect recv() to return -1 and have errno / WSAGetLastError() set to EAGAIN / WSAEWOULDBLOCK if the server is busy, but no ... recv() just returns 0. Regards, John Falling You - exploring the beauty of voice and sound http://www.fallingyou.com Sat, 28 Oct 2006 00:22:25 GMT http://CPP.tribe.net/thread/065cf463-a37c-430d-9ffc-abb48704a7c1#9886d0f0-de26-4c10-87f3-2042b4a6d850 John Michael 2006-10-28T00:22:25Z