setsockopt and socket's I/O mode

Hi All,

Is there any way to deal with socket's I/O mode using setsockopt()
API, like setting it in to block or non-block I/O mode.
Though I think using SO_RCVTIMEO option we can only SIMULATE with
these modes, not EXACTLY change the socket's I/O mode, as we can do
with ioctlsocket() in Windows and ioctl() in Linux.

Do both of them internally do the same job while setting socket's I/O
mode.

One more thing it is specified that, while using
setsockopt(SO_RCVTIMEO) "If a send or receive operation times out on a
socket, the socket state is indeterminate, and should not be used; TCP
sockets in this state have a potential for data loss, since the
operation could be canceled at the same moment the operation was to be
completed."

Is above statement also true while setting socket's I/O mode as
non-blocked by ioctlsocket/ioctl(FIONBIO), and a receive return with
-1 if there is nothing to receive.

Any comment would be appreciated.


Rajat

"Rajat" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...

> Is there any way to deal with socket's I/O mode using setsockopt()
> API, like setting it in to block or non-block I/O mode.
> Though I think using SO_RCVTIMEO option we can only SIMULATE with
> these modes, not EXACTLY change the socket's I/O mode, as we can do
> with ioctlsocket() in Windows and ioctl() in Linux.

Yes, but you're bett off using 'fcnt' for this purpose.

> Do both of them internally do the same job while setting socket's I/O
> mode.

Yes.

> One more thing it is specified that, while using
> setsockopt(SO_RCVTIMEO) "If a send or receive operation times out on a
> socket, the socket state is indeterminate, and should not be used; TCP
> sockets in this state have a potential for data loss, since the
> operation could be canceled at the same moment the operation was to be
> completed."

Right, because this times out the actual operation, not the attempt to
get the results of the operation or the attempt to initiate it.

> Is above statement also true while setting socket's I/O mode as
> non-blocked by ioctlsocket/ioctl(FIONBIO), and a receive return with
> -1 if there is nothing to receive.

No. Non-blocking sockets do not timeout the actual send or receive
operations, they timeout your attempt to put data in the queue to be sent or
your attempt to retrieve data that has been received.

DS

"David Schwartz" <(E-Mail Removed)> wrote in message news:<cvvuc2$gka$(E-Mail Removed)>...
> "Rajat" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
>
> > Is there any way to deal with socket's I/O mode using setsockopt()
> > API, like setting it in to block or non-block I/O mode.
> > Though I think using SO_RCVTIMEO option we can only SIMULATE with
> > these modes, not EXACTLY change the socket's I/O mode, as we can do
> > with ioctlsocket() in Windows and ioctl() in Linux.
>
> Yes, but you're bett off using 'fcnt' for this purpose.
>
> > Do both of them internally do the same job while setting socket's I/O
> > mode.
>
> Yes.
If you are agreeing that using setsockopt() we are just SIMULATING the
socket's I/O behaviour, Then how come both of them do the SAME job
internally.
Like using setsockopt() with SO_RCVTIMEO, if we pass some low timeout
value which is greater than zero(0), the socket will feel like
non-blocking socket. If we pass zero(0) as timeout value then the
receive timeout time will be infinite, So it will feel like blocked
I/O. But it is not exactly the case.

>
> > One more thing it is specified that, while using
> > setsockopt(SO_RCVTIMEO) "If a send or receive operation times out on a
> > socket, the socket state is indeterminate, and should not be used; TCP
> > sockets in this state have a potential for data loss, since the
> > operation could be canceled at the same moment the operation was to be
> > completed."
>
> Right, because this times out the actual operation, not the attempt to
> get the results of the operation or the attempt to initiate it.
>
> > Is above statement also true while setting socket's I/O mode as
> > non-blocked by ioctlsocket/ioctl(FIONBIO), and a receive return with
> > -1 if there is nothing to receive.
>
> No. Non-blocking sockets do not timeout the actual send or receive
> operations, they timeout your attempt to put data in the queue to be sent or
> your attempt to retrieve data that has been received.
>
> DS

"David Schwartz" <(E-Mail Removed)> wrote in message news:<cvvuc2$gka$(E-Mail Removed)>...
> "Rajat" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
>
> > Is there any way to deal with socket's I/O mode using setsockopt()
> > API, like setting it in to block or non-block I/O mode.
> > Though I think using SO_RCVTIMEO option we can only SIMULATE with
> > these modes, not EXACTLY change the socket's I/O mode, as we can do
> > with ioctlsocket() in Windows and ioctl() in Linux.
>
> Yes, but you're bett off using 'fcnt' for this purpose.
>
> > Do both of them internally do the same job while setting socket's I/O
> > mode.
>
> Yes.
If you are agreeing that using setsockopt() we are just SIMULATING the
socket's I/O behaviour, Then how come both of them do the SAME job
internally.
Like using setsockopt() with SO_RCVTIMEO, if we pass some low timeout
value which is greater than zero(0), the socket will feel like
non-blocking socket. If we pass zero(0) as timeout value then the
receive timeout time will be infinite, So it will feel like blocked
I/O. But it is not exactly the case.

>
> > One more thing it is specified that, while using
> > setsockopt(SO_RCVTIMEO) "If a send or receive operation times out on a
> > socket, the socket state is indeterminate, and should not be used; TCP
> > sockets in this state have a potential for data loss, since the
> > operation could be canceled at the same moment the operation was to be
> > completed."
>
> Right, because this times out the actual operation, not the attempt to
> get the results of the operation or the attempt to initiate it.
>
> > Is above statement also true while setting socket's I/O mode as
> > non-blocked by ioctlsocket/ioctl(FIONBIO), and a receive return with
> > -1 if there is nothing to receive.
>
> No. Non-blocking sockets do not timeout the actual send or receive
> operations, they timeout your attempt to put data in the queue to be sent or
> your attempt to retrieve data that has been received.
>
> DS

"Rajat" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...

> "David Schwartz" <(E-Mail Removed)> wrote in message
> news:<cvvuc2$gka$(E-Mail Removed)>...

>> "Rajat" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed) om...
>>
>> > Is there any way to deal with socket's I/O mode using setsockopt()
>> > API, like setting it in to block or non-block I/O mode.
>> > Though I think using SO_RCVTIMEO option we can only SIMULATE with
>> > these modes, not EXACTLY change the socket's I/O mode, as we can do
>> > with ioctlsocket() in Windows and ioctl() in Linux.
>>
>> Yes, but you're bett off using 'fcnt' for this purpose.
>>
>> > Do both of them internally do the same job while setting socket's I/O
>> > mode.
>>
>> Yes.

> If you are agreeing that using setsockopt() we are just SIMULATING the
> socket's I/O behaviour, Then how come both of them do the SAME job
> internally.

I didn't say SO_RCVTIMEO does the same thing as fcntl. I said setting a
socket non-blocking does the same thing regardless of what method you use to
do it. SO_RCVTIMEO does not make a socket non-blocking.

> Like using setsockopt() with SO_RCVTIMEO, if we pass some low timeout
> value which is greater than zero(0), the socket will feel like
> non-blocking socket. If we pass zero(0) as timeout value then the
> receive timeout time will be infinite, So it will feel like blocked
> I/O. But it is not exactly the case.

Right. In fact, I wouldn't compare a transmit or receive timeout to a
non-blocking socket. One has to do with timing out the I/O itself, the other
has to do with how long you wait, but it has no effect on the I/O itself.

DS

In comp.os.linux.networking Rajat <(E-Mail Removed)> wrote:

> If you are agreeing that using setsockopt() we are just SIMULATING the
> socket's I/O behaviour, Then how come both of them do the SAME job
> internally.
> Like using setsockopt() with SO_RCVTIMEO, if we pass some low timeout
> value which is greater than zero(0), the socket will feel like
> non-blocking socket. If we pass zero(0) as timeout value then the
> receive timeout time will be infinite, So it will feel like blocked
> I/O. But it is not exactly the case.

First, SO_RCVTIMEO is not overly portable, so portable code cannot
rely upon it.

Second, a really small timeout will only feel like a non-blocking
socket if the stack which happens to implement the SO_RCVTIMEO does
not subscribe to the POSIXy belief that setting a timeout of N time
units means that the timeout will be _at least_ N time units and allow
a timeout of less than a tick to be no timeout at all. On those
systems that do subscribe to the belief that timout settings are for
_at least_ that length, even a timeout setting of a femtosecond
will be a timeout of one tick.

And that will be >>>>> than the time for a non-blocking socket.

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...