Andrew writes:
> I have a client process that reads a file of transactions, builds an XML
> format buffer and posts out on port 80.
>
> Every time a record is read and XML build done, an IPCDEST, IPCCONNECT,
> IPCRECV (validate the vc-desc), IPCSHUTDOWN (release socket), IPCSEND and
> IPCSHUTDOWN is performed.

The IPCRECV doesn't "validate the vc-desc", it actually is the first call in
your sequence which will initiate any network activity.  It is the call that
actually establishes the connection, therefore it is the call which will
return any errors encountered during the connection process.

> This works erratically. Sometimes I get a socket timeout on the IPCRECV
> halfway through sending e.g. on the 40th record having posted the previous
> 39 successfully.

Sounds like you're talking to a remote web server of some sort.  If you're
generating these requests very rapidly, you might perhaps exceed the
server's ability to accept connections, at which point new connections would
probably fail, though more likely with an error other than a timeout.

Also you ought to make sure you're performing the IPCSHUTDOWNs properly
(i.e. allowing for a graceful release of the connection) and you should at
least make sure that the IPCSHUTDOWNs are not all failing and leaving lots
of half open connections laying around.  If you have Glance, check to see
that the number of "open files" for the process isn't just increasing
without bound.  Sockets show up as open files without names in Glance and
similar tools.  This only applies really if the process continues to run
after each connection rather than starting a new program instance for each
"record".

If there's any way to send multiple "records" without starting a new
connection, you'll probably find that things are more reliable with fewer
connection requests (and thus fewer opportunities for the server to not be
available for one reason or another in the middle of all your "records").

> Not only does this trash my posting process but also appears to disconnect
> some Reflection sessions with a 'Telnet session has been
> disconnected' msg.

This *might* indicate a more serious bug in the 3000 networking code, or
something similar, as this shouldn't be able to happen regardless of what
your one process does with NetIPC.  It could also be that you've got an
unrelated network problem which is affecting both your telnet sessions and
is causing your connection failures in NetIPC at the same time.

> Anyone seen this before and would extending the wait of the IPCRECV make a
> difference (assuming its a performance thing)

I believe that (NetIPC) vc sockets have a default timeout of 60 seconds if
you don't set your own, so one possibility is that the server simply gets
backed up to the point that it takes longer than a minute to respond to your
connection request.  You can explicitly set the timeout on the vc (as soon
as you get the vc from IPCCONNECT) either to a longer value or to zero to
disable the timeout.

G.