I cant see why my recv() is always returning 1, no more no less.
So it wont ever come out of while().
Code:
while(i = recv(mySocket, buffer, sizeof buffer, 0 ) >0)
{
str1 = buffer;
str2 += str1;
cout << i << endl;
}
Printable View
I cant see why my recv() is always returning 1, no more no less.
So it wont ever come out of while().
Code:
while(i = recv(mySocket, buffer, sizeof buffer, 0 ) >0)
{
str1 = buffer;
str2 += str1;
cout << i << endl;
}
Bad operator precedence. You need:
Code:
while( ( i = recv(mySocket, buffer, sizeof buffer, 0 ) ) >0)
{
str1 = buffer;
str2 += str1;
cout << i << endl;
}
Ah, cool, thank you Brewbuck! :)
However 'i' isnt 1 anymore, it always stays in the loop until it is disconnected from the client.
Shouldnt blocking sockets stop blocking once they recieved data?
I dont understand why would it stay in the loop.
Now, what the heck is a NON_BLOCK socket? Do you mean an O_NONBLOCK socket? ;) (See the [url=http://linux.die.net/man/2/open]man page for open()[/b] for more details). You can also use fcntl to change the flags on a file descriptor after you've opened it.
Thanks for the help MK27 and Strange!
No its not working against >-1 either.
I guess the only way is to first send the size and then the data if we have a lot to send.
Blocking sockets do essentially this:
In other words, the recv() call "blocks" the current thread of execution until there is something to read.Code:recv(sockDescriptor, sockBuf, sockBufSize); // waits forever for input if non comes
Note that the thread or process this call is in is essentially halted until there is activity on the socket, behavior that is often undesirable for a number of reasons. For anything non-trivial try non-blocking sockets are called for, first make sure there is something to read with select():
Note: this code has been shortened from real code to simply illustrate the use of a non-blocking scheme. Production code would look different. Also it may seem stupid resetting the timeout value every time but (as I found out on a project at work) Linux actually decrements that value so if you just reused the timeout value your timeout would get shorter and shorter every time until it was effectively 0, binding up the CPU, bad juju in any application...Code:while(!bExitFlag)
{
struct timeval tv;
fd_set readfds;
int sockDescCount = 0;
tv.tv_sec = 2;
tv.tv_usec = 500000;
FD_ZERO(&readfds);
FD_SET(sockDescriptor, &readfds);
sockDescCount++;
// don't care about writefds and exceptfds:
select(sockDescCount+1, &readfds, NULL, NULL, &tv);
if (FD_ISSET(sockDescriptor, &readfds))
{
printf("Socket has data!\n");
recv(sockDescriptor, workBuf, workBufSize);
// do something with it
}
else
printf("Timed out so do some other work, check for exit flags, etc.\n");
}
The reason for that behavior is to make it easier to restart select() when a signal interrupts it. In general if some API takes a non-const pointer you should always assume that it could change the value, so it's correct to reset the timeout each time in any case.
Thank you Jeff and Brewbuck!
Can i use select() in a win32(non console) program?
Ducky; my windows socket days are aways behind me now but as I recall, WinSock has their own almost-workalikes for the whole BSD socket layer, of which select() is a part. Might be WinSelect() or something like that. Select() on linux is really powerful because everything is considered a file (network, files, even the sound card) so you can for example put a watch on a file to tell then it has been read from, written to, errored or any combination of the above. Also in Linux there is the poll() function which works differently and so is useful for different things like if you just want to watch a single descriptor (select() you can watch many)...
Cool, thanks Jeff ill look it up.