ail.comSocket not blocking
-
Hi, I've created a Socket (TCP/IP - Synchronous Socket - SOCK_STREAM) program in which I've spawned a new thread to accept client connections. Again, for every accepted connection through a new client socket, i've spawned another new thread for message transaction. Here, the Receive function does not block until the data is filled in the buffer. Instead, the receive function tries to read data which is either NULL or junk, which leads to assertion failure. Is there any solution to make the client socket block untill receive? Or does a thread affect the state of the socket by any chance. shenthil senthilkkumar@rediffmail.com
-
Hi, I've created a Socket (TCP/IP - Synchronous Socket - SOCK_STREAM) program in which I've spawned a new thread to accept client connections. Again, for every accepted connection through a new client socket, i've spawned another new thread for message transaction. Here, the Receive function does not block until the data is filled in the buffer. Instead, the receive function tries to read data which is either NULL or junk, which leads to assertion failure. Is there any solution to make the client socket block untill receive? Or does a thread affect the state of the socket by any chance. shenthil senthilkkumar@rediffmail.com
The receive function of a connected socket is very much blocking provided you use CSocket::Receive or the Winsock API' recv (and not CAsyncSocket). The reasons for a receive to not block might be: 1.The passed in data buffer is full with data 2.The connection went lost So, check for the above. Peter Molnar
-
Hi, I've created a Socket (TCP/IP - Synchronous Socket - SOCK_STREAM) program in which I've spawned a new thread to accept client connections. Again, for every accepted connection through a new client socket, i've spawned another new thread for message transaction. Here, the Receive function does not block until the data is filled in the buffer. Instead, the receive function tries to read data which is either NULL or junk, which leads to assertion failure. Is there any solution to make the client socket block untill receive? Or does a thread affect the state of the socket by any chance. shenthil senthilkkumar@rediffmail.com
I have never had problems with blocking sockets and threads. Anyway, I assume you are just using plain socket, accept and recv. If then the only thing that comes to mind is that you are mistaken the length of the buffer you are passing (the buffer you expect filled ) with the actual number of bytes read. if you try something like this do you get to DebugBreak()? int received = recv( s, buf, sizeof buf, 0 ); if( ( SOCKET_ERROR == received ) && (WSAEWOULDBLOCK == WSAGetLastError() ) ) { //something has changed your socket to non-blocking mode DebugBreak(); } else { CopyMemory( workerBuf, buf, received ); //work with worker buf using the n received bytes } Hope this helps Gabriel Old C programmers never die. They just cast into void
-
I have never had problems with blocking sockets and threads. Anyway, I assume you are just using plain socket, accept and recv. If then the only thing that comes to mind is that you are mistaken the length of the buffer you are passing (the buffer you expect filled ) with the actual number of bytes read. if you try something like this do you get to DebugBreak()? int received = recv( s, buf, sizeof buf, 0 ); if( ( SOCKET_ERROR == received ) && (WSAEWOULDBLOCK == WSAGetLastError() ) ) { //something has changed your socket to non-blocking mode DebugBreak(); } else { CopyMemory( workerBuf, buf, received ); //work with worker buf using the n received bytes } Hope this helps Gabriel Old C programmers never die. They just cast into void
-
Gabriel, receive function (CSocket::Receive) neither returns SOCKET_ERROR nor WASEWOULDBLOCK ), rather it simply crashes out. even while debuggin, when the receive function returns, the application crashes. shenthil shenthil
Shenthil, I would like to help but i just know about plain sockets. I don´t have any idea about how they work in MFC, even less what the problem could be. About the subject of the original post (the socket not bloking,) CSocket inherits from CAsyncSocket which is asynchronous, and taking a quick glance at the code you can see CSocket simulates a blocking socket using a loop. But i don´t think this is the cause of the problem. If your threads are just pumping bytes from a network connection and you need to work directly with them you are better off using and alternative to CSocket, because there is a lot of overhead in the way they work (asyncrhonous notifications through a windows message queue) which was the only option when they appeared in win3.1 because the apps were single threaded and there was no real multitasking in the OS Gabriel Old C programmers never die. They just cast into void
-
Shenthil, I would like to help but i just know about plain sockets. I don´t have any idea about how they work in MFC, even less what the problem could be. About the subject of the original post (the socket not bloking,) CSocket inherits from CAsyncSocket which is asynchronous, and taking a quick glance at the code you can see CSocket simulates a blocking socket using a loop. But i don´t think this is the cause of the problem. If your threads are just pumping bytes from a network connection and you need to work directly with them you are better off using and alternative to CSocket, because there is a lot of overhead in the way they work (asyncrhonous notifications through a windows message queue) which was the only option when they appeared in win3.1 because the apps were single threaded and there was no real multitasking in the OS Gabriel Old C programmers never die. They just cast into void
-
Shenthil, If you refer to stop pumping the messages that are sent to you over the network, unless you call Receive or recv, the data is going to stand still until your winsock implementation runs out of network buffer space. If you refer to message pumping from the window queue as Receive does, this is not desirable because this is intrinsic to the mechanism CSocket uses. Here at CP in the Internet & Networking section you have plain sockets programming tutorials and classes, and also MFC CSocket derived classes. (Nish has written great tutorials on sockets) I´m biased but IMHO CSocket misuses resources and adds uneeded complexity. Hope this helps Gabriel Old C programmers never die. They just cast into void
-
Shenthil, If you refer to stop pumping the messages that are sent to you over the network, unless you call Receive or recv, the data is going to stand still until your winsock implementation runs out of network buffer space. If you refer to message pumping from the window queue as Receive does, this is not desirable because this is intrinsic to the mechanism CSocket uses. Here at CP in the Internet & Networking section you have plain sockets programming tutorials and classes, and also MFC CSocket derived classes. (Nish has written great tutorials on sockets) I´m biased but IMHO CSocket misuses resources and adds uneeded complexity. Hope this helps Gabriel Old C programmers never die. They just cast into void
-
Thanks Gabriel. Now I've changed the algorithm, but the problem is still unsolved. Shenthil
Is your app still crashing? What´s the error? Access violation? Gabriel Old C programmers never die. They just cast into void
-
Is your app still crashing? What´s the error? Access violation? Gabriel Old C programmers never die. They just cast into void