Thread: FIONREAD + WSARecv = Operation not supported (10054)

I am trying to read data from an HTTP server asynchronously, and trying to respond to FD_READ notifications properly. I made code to respond by doing WSAIoctl + FIONREAD to determine the data left in the buffer, and then allocated memory for it, and read from the buffer. Here is my code in response to an FD_READ

Code:

					DWORD         bytesOutput;
					DWORD         bytesRecvd;
					DWORD         flags;
					WSABUF        wsaBuffer;

					int           ret;
					char *        buf;
					unsigned long toBeRead;

					ret = ::WSAIoctl
						(wParam, FIONREAD, 0, 0, &toBeRead, 
						sizeof toBeRead, &bytesOutput, 0, 0);

					if(ret != SOCKET_ERROR && bytesOutput == sizeof toBeRead)
					{
						wsaBuffer.buf = new char[toBeRead + 1];
						wsaBuffer.len = toBeRead;

						ret = ::WSARecv
							(wParam, &wsaBuffer, 1, &bytesRecvd, &flags, 0, 0);

						if(ret == SOCKET_ERROR)
						{
							ErrorMessage
								(_T("WSARecv: %d"), ::WSAGetLastError());
						}

						wsaBuffer.buf[bytesRecvd] = 0;
					}

The first FD_READ notifications results in WSARecv failing with error 10045 - Operation not supported

Originally Posted by MSDN

The attempted operation is not supported for the type of object referenced. Usually this occurs when a socket descriptor to a socket that cannot support this operation is trying to accept a connection on a datagram socket

In addition, I get an exception (don't know if it matters)

First-chance exception at 0x00401407 in Dialog Testing - Modal + Icon.exe: 0xC0000005: Access violation writing location 0x00dfee60.
Unhandled exception at 0x00401407 in Dialog Testing - Modal + Icon.exe: 0xC0000005: Access violation writing location 0x00dfee60.

So I am trying to make it very simple. No determining how much data is in the buffer, very basic, this code is failing.

Code:

		DWORD         bytesRecvd;
		DWORD         flags;
		WSABUF        wsaBuffer;

		int           ret;
		bool          succeeded = true;


		wsaBuffer.buf = new char[256];
		wsaBuffer.len = 255;

		ret = ::WSARecv
			(wParam, &wsaBuffer, 1, &bytesRecvd, &flags, 0, 0);

		if(ret == SOCKET_ERROR)
		{
			ErrorMessage
				(_T("WSARecv: %d"), ::WSAGetLastError());
			succeeded = false;
		}
		else
		{
			wsaBuffer.buf[bytesRecvd] = 0;
		}

And I get very unexplainable (by me ) behavior.

Most of the time, I am able to read most of the data successfully with WSARecv, until I get an FD_CLOSE and then I get a 10038 (Operation on non-socket) error.

But some of the time, that code will be run several times, each time WSARecv returning an error 10045 (Operation not supported), and then I get an FD_CLOSE, closesocket the socket, and then get a 10038 as it's trying to still read some data (and failing anyways).

Any ideas?

I'm assuming that you are using WSAsyncSelect. Is is possible that you have a message conflict? Typically, you should use a message id above WM_APP (eg. WM_APP + 1), although any message value above WM_USER should be fine. Other than that, could you be missing a break statement?

I do not think I am missing a break statement. My message is WM_ASYNC_IO defined as WM_USER + 4337 (I say someone use their address for it, I did too). But I think it is okay, and I think I got it to kind of work like this. First, I found that MSDN said this:

FD_CLOSE should only be posted after all data is read from a socket, but an application should check for remaining data upon receipt of FD_CLOSE to avoid any possibility of losing data.

So I did something kind of roundabout. After every FD_READ message, I ran this code:

Code:

					ret = ::WSAIoctl
						(wParam, FIONREAD, 0, 0, &toBeRead, 
						sizeof toBeRead, &bytesOutput, 0, 0);

					if(ret != SOCKET_ERROR && bytesOutput == sizeof toBeRead)
					{
						if(toBeRead == 0)
						{
							stillDataLeft = false;
							::SendMessage(hwnd, WM_ASYNC_IO, wParam, MAKELPARAM(FD_CLOSE, 0));
							break;
						}
					}

stillDataLeft is a static boolean. I synthesize an FD_CLOSE message if there is no more data left. In FD_CLOSE, I check if there isStillDataLeft

Code:

					if(!stillDataLeft)
					{
						closesocket(wParam);
					}

It very much of the time. But on 2 seperate occaisions since I've implemented this code, I have still gotton 10045 errors. It seems to be extremely infrequent, but it's still a little troubling. I may test out this code a little more, I think that this is kind of an okay thing that I have done. Synthesizing the FD_CLOSE notification was a little wierd, but I think it's okay. If it isn't please tell me. I'm also trying to figure out an intelligent way to handle the winsock errors, but I think I can figure it out.

I would add some sanity code to check the value of wParam and make sure it is actually your socket.

For the closing issue, have a look at the documentation for the shutdown function.

I'm not sure why Norton would be causing these errors, certainly I don't think it would cause exceptions. There is something weird happening here, but I'm not sure what. If you like, you could post a minimal program that demonstrates the errors and I will take a look.

In FD_CLOSE, you should just receive any remaining data with WSARecv, and then call closesocket. You should use shutdown when you want to finish the connection rather than synthesising an FD_CLOSE notification.

>> Edit 1: Is there any reason why wParam would not be my socket? Should I make like, WSASocket store a static socket so I can compare? <<

No particular reason, but when you are getting unexplained errors, it is a good idea to add sanity tests. You can store the socket value in a global and check that wParam is equal.

!! I've just noticed that flags is an [in/out] argument and you are passing it to WSARecv uninitialised. I think this is probably the primary cause of the errors you are getting. Setting it to zero should be fine.

Okay. This is so convincing me to initialize everything. Many many thanks!