Operating System - OpenVMS
1748149 Members
3645 Online
108758 Solutions
New Discussion юеВ

Re: Programmatically enumerate open sockets

 
SOLVED
Go to solution
Richard J Maher
Trusted Contributor
Solution

Re: Programmatically enumerate open sockets

Hi Chorneck,

On re-reading this thread, I see that you are new(ish) to VMS, so I might not have been as helpful as I could've. Please see attached for an example of what Steven S was talking about. (Or if I'm wrong, I'm sure he'll correct me with his version.)

I would've given a more complete version but this has honestly taken over two full days and (unlike the IMM team that have cost centres galore - how's gSOAP going btw) I can't spend anymore "free" time on it :-(

Yes, I did imply that this was easy, and I stand corrected. Moving forward, here are some issues you should be aware of: -

. This example looks specifically at the BG driver. While Multinet and TCPWare both support the BG driver they also have other "lesser" drivers that are probably being used for Telnet, or FTP and so on. I don't have priv on DEATHROW to test it but maybe Richard W will give it a go?

. I successfully tested this on Alpha VMS 7.2-2 UCX 5.1 with no (visible) ill effects. Please be aware that with VAX/VMS 6.2 UCX 4.1 all your Telnet sessions stop working :-( Check the supportability of assigning an additional channel to a BG device that doesn't have ucx$c_share set.

. I haven't bothered with the IPv6 code for socket names but that won't be hard.

. I don't get IP address returned for Telnet connections for some reason?

. Full duplex close option doesn't seem identifyable

. I don't know if there is a ACP/QIO Stats call to get the number of I/Os bytes etc? a la mode de $UCX SH DEV/FULL

. Maybe this should all be done by walking some UCB chain?

OTY (or anyone else)

Cheers Richard Maher
chorneck
New Member

Re: Programmatically enumerate open sockets

Thanks for all the replies! I think the code provided by Richard does what I want.

Regards,
chorneck
Richard Whalen
Honored Contributor

Re: Programmatically enumerate open sockets

I don't have a COBOL compiler on my systems, so I can't test Richard Maher's program on TCPware or MultiNet. TCP/IP services also supports the INET device that MultiNet and TCPware provide, though it is probably not commonly used.
Richard J Maher
Trusted Contributor

Re: Programmatically enumerate open sockets

Hi Richard,

> I don't have a COBOL compiler on my systems,

You should get out more :-)

> so I can't test Richard Maher's program
> on TCPware or MultiNet.

If anyone has SHARE privilege on the Deathrow cluster, I have put a copy of the code, and built an executable on GEIN: -

DISK$USERS:[USERS.TIER3]SOCKET_SCAN.EXE

Richard, could you also please tell me/everyone the API for getting this sort of statistics information from the socket: -

Total buffer alloc 0 0
Total buffer limit 70080 70080
Buffer or I/O waits 0 0
Buffer or I/O drops 0 0
I/O completed 5 23
Bytes transferred 148 1219

Cheers Richard Maher
chorneck
New Member

Re: Programmatically enumerate open sockets

What would be the impact of assigning an additional channel to a BG device and then subsequently deassigning that channel?

The HP TCP/IP Services guide seems to suggest that it actually closes the port and clears all pending I/O operations if I am understanding this correctly.

To quote a bit...

After all communication is completed, use the $DASSGN system service to free an I/O channel. A $DASSGN operation executed on a channel associated with a network pseudodevice does the following:

* Ends all pending operations to send or receive data at $QIO level ($CANCEL system service).
* Clears the port associated with the channel. When executing the $DASSGN system service for TCP sockets, the socket remains until the connection is closed on both the local and remote sides.
* Ends all communications with the network pseudodevice that the I/O channel identifies.
* Frees the channel associated with the network pseudodevice. An I/O channel can be deassigned only from an access mode equal to or more privileged than the access mode from which the original channel assignment was made.


Does anyone have any insight on this? Am I just misunderstanding how this program is working?


Thanks!
David Jones_21
Trusted Contributor

Re: Programmatically enumerate open sockets

"What would be the impact of assigning an additional channel to a BG device and then subsequently deassigning that channel?

The HP TCP/IP Services guide seems to suggest that it actually closes the port and clears all pending I/O operations if I am understanding this correctly."

I have an application that hands off accepted connections to worker processes, which involves the listener process setting the socket shared and deassinging the channel after the worker has assigned its own channel to the BG device. Normally, rundown operations on devices are only triggered when the last channel is deassigned.
I'm looking for marbles all day long.
chorneck
New Member

Re: Programmatically enumerate open sockets

I ended up throwing together a C program based on Richard's COBOL program. I am attaching the code if anyone is interested. However, as Richard mentioned, there are a few side effects that I discovered while testing on OpenVMS Alpha 7.3-2/TCPIP Services v5.4 ECO 6.

1) I discovered that executing QIO requests on BG* devices that are owned by the TCPIP Ancillary Control Process is a bad idea. It seemed to cause random freezes in TCPIP services and no one else could log into the node via Telnet or SSH until the node was rebooted. Therefore, I put a check in so that the code does not execute the QIOW requests on devices where Owner PID == ACP PID.

2) Once I worked around problem 1, I discovered that Richard was right about the Telnet sessions. For some reason, I cannot seem to get their IP Addresses. SSH sessions are another story. I was able to get their addresses, but the end result was that the SSH sessions that I was able to retrieve information for stopped working. Apparently, the SSH sessions don't handle QIO requests well either.


Thank you to everyone for all the help!
Richard J Maher
Trusted Contributor

Re: Programmatically enumerate open sockets

Hi Corneck,

Short of opening a formal support call, you'd need someone with Richard Whalen's level of detailed knowledge to tell you, or access to the VMS sources for $UCX SHOW DEV

Cheers Richard Maher

PS. When you find out, please report back :-)
Richard W Hunt
Valued Contributor

Re: Programmatically enumerate open sockets

Maybe I'm lost here and don't follow what you are trying to do, but I don't think you can just assign a channel to a BG device. They are "template-created" devices in that there is really only device BG0 and all other BG devices are cloned. When I look at the device characteristics of the BG devices on my system, the SHR flag is 0 i.e. not shareable. So I don't think you can just name a BG device and open it.

The closest analogy is the MBA device, mailboxes, where you have to use a specific system call, CREMBX, to clone from MBA0 (yes, another template UCB device) before you can open a channel to it. While I won't swear to it, I think BG devices are similar except I don't know how to force a clone.

If you really created one, you could maybe see WHICH BG you got. Doing it that way means you get a fresh BG and don't have to try to share one. You also would then avoid interfering with arbitrary BG devices engaged in protocol exchange operations.

Or was that too simple-minded for what you were really looking at?
Sr. Systems Janitor