Re: Socket question -- RPG400-L

Hello,

> I have a RPG program that listens on a socket for wireless CE devices to
> connect to.  The wireless network seems unstable in that I get a lot of
> entries on my exception set of my select.

The exception set has nothing to do with network errors.

> I had been interpreting this as the TCP connection was dropping and I
> would close it and reinitialize it.  The problem is that if I miss one
> of the TCP messages the handheld will loop indefinitely waiting for it.

When working with communications, there will always be errors.  Even more
so with wireless communications where movement and interference are
commonplace.  Therefore, if the handheld is getting stuck because you did
not receive a message, the handheld's software needs to be fixed.


> Then I read the archives and read that the only thing that sets the
> exception set is OOB data, but it was dated in May 2002.  Is this still
> the case or would a network failure (somebody kicks the hub cord and
> unplugs it...) also cause the exception set to be turned on?  IBM
> explains how to check the set, but not what would trigger it.

This is still the case.  And, IBM does discuss what will trigger an event
down at the bottom of the Info Center page for select().  It's in the
section entitled "Usage Notes."

It's possible that when the handheld encounters a network error, it sends
OOB data to see if the TCP session is recoverable.  I've heard of people
doing this, though I haven't encountered it directly -- but then I don't
work with handhelds.  If that's the case, these messages actually mean
that the connection is ALIVE, rather than the opposite. ;)

> If there is OOB data, how can I read it, and what would I do with it if
> I did (my handheld application does not send any OOB data).

You set the "flags" parameter of the recv() API to the constant MSG_OOB in
order to tell recv() to read the OOB data instead of the regular data.
Here's the definition that I have for MSG_OOB

     D*                                               out-of-band data
     D MSG_OOB         C                   CONST(4)

Alternately, you can use setsockopt() to set the SO_OOBINLINE option on
your socket.  That tells recv() to read out-of-band data inline with
the rest of your data.  Here's my definition fo SO_OOBINLINE:

     D*                                          out-of-band data inline
     D SO_OOBINLINE    C                   35


> Lastly, if the socket does disconnect with a message in the TCP buffer,
> is there some way for my RPG program to get that message back so that it
> can send it again after the socket reconnects?

When there's a network error, normally the system sets on a flag in the
read_set. That will convince your program that there's data to read...
when it does the recv() -- or read() -- API, it will get any data that's
waiting in the buffer first, and then get an error when the buffer is
empty to tell you that the connection was closed.


> Would setting linger to wait for a few seconds help me with this?

Not for this, I don't think?

Linger controls how long data remains in the system's write buffer after
the close() API is issued.  That allows you to do a send(), and then
without waiting, do a close().  The amount of time that the system will
keep the data after the close() is controlled by the linger value.  If
linger is set to 2 seconds, and the data has not been removed from the
send buffer in 2 seconds, the system will discard it.

My advice is to never rely on the linger value.  Keeping data around after
a socket closes is wasteful on system resources.  Design the application
protocol so that notifications are sent when both sides are ready to
disconnect, that way linger is irrelevant.

Good Luck