Using bind() with VxWorks sockets

[Todd Rubano]

Several days ago there was a post about re-using the same port
with multiple calls to a routine which sets up TCP/IP socket
connection between the host and the target. I was having the
same trouble and thought my problems would be answered with the
'use setsockopt to allow SO_REUSEADDR' hint. Unfortunately
they were not.

I'm using the target (Force-30 board w/ VxWorks 5.1.1) as the
server and the Unix host as the client. Like the previous poster,
I can spawn the server program once and talk to it as often as
I'd like, but if I delete its task and restart it I get the
dreaded 'S_errno_EADDRINUSE' error with bind().

So, I'm looking for other ideas. Has anyone here ever set up
the target machine as the server? Any/all tips would be
greatly appreciated.

Thanks in advance,

Todd
(t...@tally.hsc.colorado.edu)

[Joe Bonaker]

In article p...@tali.hsc.colorado.edu, tjr@tally (Todd Rubano) writes:

>Several days ago there was a post about re-using the same port
>with multiple calls to a routine which sets up TCP/IP socket
>connection between the host and the target. I was having the
>same trouble and thought my problems would be answered with the
>'use setsockopt to allow SO_REUSEADDR' hint. Unfortunately
>they were not.
>
>I'm using the target (Force-30 board w/ VxWorks 5.1.1) as the
>server and the Unix host as the client. Like the previous poster,
>I can spawn the server program once and talk to it as often as
>I'd like, but if I delete its task and restart it I get the
>dreaded 'S_errno_EADDRINUSE' error with bind().

When a Unix process is terminated, the operating system performs
cleanup: deallocating memory, closing open file descriptors and
sockets, etc. In contrast, VxWorks doesn't cleanup for a task which
has been deleted. All of its memory remains allocated and its
files/sockets are left open. A server application writer may be faced
with the additional burden of providing an orderly killMyApp() function
and/or signal handler which closes the books prior to calling
taskDelete(2).

Short of rebooting your system, you may be able to manually close the
decedent's TCP listner socket from the VxWorks shell. The
inetstatShow(2) and iosFdShow(2) commands can be used to *infer* the
correct file descriptor. Be careful: inetstatShow doesn't correlate
active sockets to their file descriptor numbers, so you'll have to do
some creative sleuthing to close the correct file descriptor(s).

Joe B.

[Chris Fortin]

Hi. The "solution" I used was to keep trying to open a socket
, starting from 5000, until I succeed. Then, have the host store
its ip address and socket number in a file. The vxworks program
is set to open the file, read the contents and try to connect
to the socket. Upon success it empties the file. If failure, sleep
for a couple seconds and try again.

This isn't elegent, but it does allow you to have the socket on amy
machine on the net that also has access to the file the info is
stored in. The vx program can also stay resident, returning to the
file query mode as host side programs come and go.

Hope this is some help, good luck

Chris
--
43 Preston Dr. Dr. Christopher Fortin hackings just another word //
N.K. R.I. 02852 for...@neptune.ele.uri.edu for nothing left \\//
(401)295 1074 for...@tautog.npt.nuwc.navy.mil to kludge \/