Is close() required after using socket_fd()

[Jeff44]

We have a network device is created with $assgn and mostly manipulated with $qio. Occasionally we need to use a function from the socket() library which does not have a $qio equivilent so we call decc$socket_fd() to associate a socket with the device.

When we're done with the device is it sufficient to call $dassgn to close the channel/device or do we also (or instead?) need to call close() on the result from socket_fd() to release some other internal structures which got created?

[Hoff]

Um, which (missing) function?

I wouldn't prefer to mix sockets and system service APIs.

With strictly system services, $deassgn is enough.

If you're going to try this mixing, then while I'd assume $deassgn is enough, I'd also write a test program and try a gazillion of whatever (missing) function might be (in a loop), and look for leaks.

[Jeff44]

The 'missing' function is select().

[Joseph Huber_1]

I have the suspicion socket_fd() is allocation memory, and $dassgn does not know of. Probably close() is the only place where this memory is returned.

The 'missing' function is select().

Using only VMS services select() is easily and more flexible replaced by a combination of async. $QIO, eventflags and/or ASTs, and either a wait for eventflags, or $hiber and awake from an AST.

[Hoff]

If you really want to do a select() and to use an approach which is synchronous, clunky, and rather more work, then just use the event flags on the $qio and issue a wait.

That's more work and more code complexity and more support, for less features and slower code. Use ASTs. Or (if you need portability, which is less likely given the use of $qio) maybe threads.

While a more modern C environment does threading and asynchronous processing rather easily, unfortunately C on VMS is rather stale. Give you're already using the $qio calls, you can get where you want with this.

Here's a generic AST example:

http://labs.hoffmanlabs.com/node/617

Though this is definitely a different application design approach for the code; this is event-driven code, rather than waiting for flags. (Which might push you back into event flag waits via lib$get_ef calls and $qio calls and the $wflor and such. Into the ancient select-style programming model.) If the event-driven code is done "right", it's often rather cleaner than the old-style select-based stuff, too.

Please consider not posting proposed solutions; certainly not in isolation. Please post problems, and background. If you should post a question on a particular solution, then you'll usually get an answer to that approach. Here's the rub with asking specific questions: the specific answer you'll (usually) get means you might (will?) miss alternative (better) solutions to your actual problem.

[Jeff44]

I suppose I should have posted a more complete reply, its for a select() on an SSLified socket. We generally do use $QIO's for managing these things however when we're asked to enable SSL, the SSL library is socket based and so we need to switch to sockets.

Thanks for all the useful comments, and the others as well. I'll write a test program which creates several sockets off a vms channel to see what happens when I close them.

[Hoff]

Ah, ssl. Ye-hah. I just did 2,000 lines of that stuff (commented C and DCL, key-generation, etc) to get that all working (simply) for a customer.

On one of the other platforms I deal with, that same support is six or eight button-presses and some simple (provided) input forms to get the keys set-up, and probably ten lines of code.

I feel your pain.

[Richard J Maher]

Would STUNNEL be of any use here?

One port for in the clear access and another for SSL?

Cheers Richard Maher

[David Jones_21]

The OpenSSL library lets you supply your own BIO (buffered I/O) object for providing the communication stream that the SSL protocol runs over. That's how the OSU web server supports SSL using $QIO interfaces to the TCP/IP stack.