• Create Account

### #ActualVortez

Posted 20 September 2013 - 06:39 PM

It is totally possible for send() to return less than the full amount of data requested to send.

Yea, that part i am aware of it. It's handled properly.

This is why you typically will want to have a queue of outgoing data, and send from this queue, and only dequeue the data that actually was sent, keeping the rest for the next time around.

That's actually not a bad idea. I was sending my data by chunks in a loop, so that's might be my problem here. Although im not sure it would help much, gotta think about it.

I need to send my data as fast as possible.

Also, public service announcement: WSAAsyncSelect() is a very old API, performs very poorly, has known implementation bugs (that Microsoft retains for compatibility reasons,) and is not portable at all. I recommend nobody use it.

That part i don't understand. I tried polling the socket with select() in my previous version of my projects, and it's seem that each time i called it, it costed me about 1-15 ms,

so that's why i used WSAAsyncSelect(), and it seem to be a lot faster this way... until it crash for no reason, probably because of the FD_WRITE message i forgot to handle.

It also make servers that handle multiples connections much easier to deal with, and require no threads to work, althrough now i think im gonna need one to write.

And i can't use blocking sockets, because it could hang my program indefinitely.

So, i don't have much other options.

Also, portability is not an issue here, im only targeting windows machines.

EDIT: That's the old code i was using to poll the socket, specifically, my CanRead() function:  (CanWrite() was pretty much identical)

//-----------------------------------------------------------------------------
//-----------------------------------------------------------------------------
{
// Setup the timeout for the select() call
timeval waitd;
waitd.tv_sec  = 0; // Make select wait up to 1 second for data
waitd.tv_usec = 1; // and 0 milliseconds.

// Zero the flags ready for using

// Set the read flag to check the write status of the socket

// Now call select
if(Res < 0) {  // If select breaks then pause for 5 seconds
//Sleep(3);  // then continue
return false;
}

return true;
} else {
return false;
}
}



The problem is, if i used waitd.tv_usec = 0; i would get errors in my program...

### #8Vortez

Posted 20 September 2013 - 06:37 PM

It is totally possible for send() to return less than the full amount of data requested to send.

Yea, that part i am aware of it. It's handled properly.

This is why you typically will want to have a queue of outgoing data, and send from this queue, and only dequeue the data that actually was sent, keeping the rest for the next time around.

That's actually not a bad idea. I was sending my data by chunks in a loop, so that's might be my problem here. Although im not sure it would help much, gotta think about it.

I need to send my data as fast as possible.

Also, public service announcement: WSAAsyncSelect() is a very old API, performs very poorly, has known implementation bugs (that Microsoft retains for compatibility reasons,) and is not portable at all. I recommend nobody use it.

That part i don't understand. I tried polling the socket with select() in my previous version of my projects, and it's seem that each time i called it, it costed me about 1-15 ms,

so that's why i used WSAAsyncSelect(), and it seem to be a lot faster this way... until it crash for no reason, probably because of the FD_WRITE message i forgot to handle.

It also make servers that handle multiples connections much easier to deal with, and require no threads to work, althrough now i think im gonna need one to write.

And i can't use blocking sockets, because it could hang my program indefinitely.

So, i don't have much other options.

Also, portability is not an issue here, im only targeting windows machines.

EDIT: That's the old code i was using to poll the socket, specifically, my CanRead() function:

//-----------------------------------------------------------------------------
//-----------------------------------------------------------------------------
{
// Setup the timeout for the select() call
timeval waitd;
waitd.tv_sec  = 0; // Make select wait up to 1 second for data
waitd.tv_usec = 1; // and 0 milliseconds.

// Zero the flags ready for using

// Set the read flag to check the write status of the socket

// Now call select
if(Res < 0) {  // If select breaks then pause for 5 seconds
//Sleep(3);  // then continue
return false;
}

return true;
} else {
return false;
}
}



The problem is, if i used waitd.tv_usec = 0; i would get errors in my program...

### #7Vortez

Posted 20 September 2013 - 06:33 PM

It is totally possible for send() to return less than the full amount of data requested to send.

Yea, that part i am aware of it. It's handled properly.

This is why you typically will want to have a queue of outgoing data, and send from this queue, and only dequeue the data that actually was sent, keeping the rest for the next time around.

That's actually not a bad idea. I was sending my data by chunks in a loop, so that's might be my problem here. Although im not sure it would help much, gotta think about it.

I need to send my data as fast as possible.

Also, public service announcement: WSAAsyncSelect() is a very old API, performs very poorly, has known implementation bugs (that Microsoft retains for compatibility reasons,) and is not portable at all. I recommend nobody use it.

That part i don't understand. I tried polling the socket with select() in my previous version of my projects, and it's seem that each time i called it, it costed me about 1-15 ms,

so that's why i used WSAAsyncSelect(), and it seem to be a lot faster this way... until it crash for no reason, probably because of the FD_WRITE message i forgot to handle.

It also make servers that handle multiples connections much easier to deal with, and require no threads to work, althrough now i think im gonna need one to write.

And i can't use blocking sockets, because it could hang my program indefinitely.

So, i don't have much other options.

Also, portability is not an issue here, im only targeting windows machines.

### #6Vortez

Posted 20 September 2013 - 06:31 PM

It is totally possible for send() to return less than the full amount of data requested to send.

Yea, that part i am aware of it. It's handled properly.

This is why you typically will want to have a queue of outgoing data, and send from this queue, and only dequeue the data that actually was sent, keeping the rest for the next time around.

That's actually not a bad idea. I was sending my data by chunks in a loop, so that's might be my problem here. Although im not sure it would help much, gotta think about it.

I need to send my data as fast as possible.

Also, public service announcement: WSAAsyncSelect() is a very old API, performs very poorly, has known implementation bugs (that Microsoft retains for compatibility reasons,) and is not portable at all. I recommend nobody use it.

That part i don't understand. I tried polling the socket with select() in my previous version of my projects, and it's seem that each time i called it, it costed me about 1-15 ms,

so that's why i used WSAAsyncSelect(), and it seem to be a lot faster this way... until it crash for no reason, probably because of the FD_WRITE message i forgot to handle.

It also make servers that handle multiples connections much easier to deal with, and require no threads to work, althrough now i think im gonna need one to write.

And i can't use blocking sockets, because it could hang my program indefinitely.

So, i don't have much other options.

### #5Vortez

Posted 20 September 2013 - 06:26 PM

It is totally possible for send() to return less than the full amount of data requested to send.

Yea, that part i am aware of it. It's handled properly.

This is why you typically will want to have a queue of outgoing data, and send from this queue, and only dequeue the data that actually was sent, keeping the rest for the next time around.

That's actually not a bad idea. I was sending my data by chunks in a loop, so that's might be my problem here. Although im not sure it would help much, gotta think about it.

Also, public service announcement: WSAAsyncSelect() is a very old API, performs very poorly, has known implementation bugs (that Microsoft retains for compatibility reasons,) and is not portable at all. I recommend nobody use it.

That part i don't understand. I tried polling the socket with select() in my previous version of my projects, and it's seem that each time i called it, it costed me about 1-15 ms,

so that's why i used WSAAsyncSelect(), and it seem to be a lot faster this way... until it crash for no reason, probably because of the FD_WRITE message i forgot to handle.

It also make servers that handle multiples connections much easier to deal with, and require no threads to work, althrough now i think im gonna need one to write.

And i can't use blocking sockets, because it could hang my program indefinitely.

So, i don't have much other options.

### #4Vortez

Posted 20 September 2013 - 06:25 PM

It is totally possible for send() to return less than the full amount of data requested to send.

Yea, that part i am aware of it. It's handled properly.

This is why you typically will want to have a queue of outgoing data, and send from this queue, and only dequeue the data that actually was sent, keeping the rest for the next time around.

That's actually not a bad idea. I was sending my data by chunks in a loop, so that's might be my problem here. Although im not sure it would help much, gotta think about it.

Also, public service announcement: WSAAsyncSelect() is a very old API, performs very poorly, has known implementation bugs (that Microsoft retains for compatibility reasons,) and is not portable at all. I recommend nobody use it.

That part i don't understand. I tried polling the socket with select() in my previous version of my projects, and it's seem that each time i called it, it costed me about 1-15 ms,

so that's why i used WSAAsyncSelect(), and it seem to be a lot faster this way... until it crash for no reason, probably because of the FD_WRITE message i forgot to handle.

It also make servers that handle multiples connections much easier to deal with, and require no threads to work, althrough i think now im gonna need one to write.

And i can't use blocking sockets, because it could hang my program indefinitely.

So, i don't have much other options.

PARTNERS