Question Stuart Strickland · Jun 24

TCP connection problems

I'm trying to open a TCP connection to a remote system. The Caché command I'm using to open the connection is OPEN "|TCP|"_PORT:(IP::"PSE"):10 where PORT is a port number in the range 40000 to 40100 and IP is a standard IPv4 addess like 10.200.100.50 the connection appears to open because $TEST becomes 1. I'm then writing to the open port with USE "|TCP|"_PORT:(::"S") WRITE "some text",*-3 It's a windows system

w $zv Cache for Windows (x86-64) 2017.2.2 (Build 865) Mon Jun 25 2018 10:45:31 EDT I'm under the impression that the O/S handles the I/O for TCP connections. Does anyone know what commands the O/S would use to perform these operations? I'm getting <WRITE> errors and the network people can't work out what is wrong with the firewall or network or their VPN setup.

Product version: Caché 2017.1
$ZV: Cache for Windows (x86-64) 2017.2.2 (Build 865) Mon Jun 25 2018 10:45:31 EDT

Comments

DC AI Bot · Jun 24 Bot

The ObjectScript commands you are using to open a TCP connection and write to it appear correct based on InterSystems IRIS documentation.

  1. Opening a TCP connection: To initiate a TCP connection, the OPEN command syntax is correct. When using OPEN "|TCP|"_PORT:(IP::"PSE"):10, PORT should be in the allowed range, and IP provided should be an IPv4 address (e.g., "10.200.100.50"). The OPEN command reserves and initiates the device for communication, setting $TEST to 1 upon success [1].

  2. Writing to the TCP connection: Using the WRITE command with USE to specify the TCP device is correct. Particularly, the control *-3 flushes the output buffer forcing a write operation to the physical device. The control ensures that data moves from the TCP device buffer to the network buffer, and then to the physical device [1][2]. In the case of TCP communication, this approach is standard for ensuring immediate data transmission without buffering [1].

  3. Operating System Handling: The TCP device I/O in InterSystems IRIS leverages underlying operating system mechanisms for network communication. ObjectScript commands such as OPEN, USE, WRITE, and CLOSE interact with these mechanisms to establish connections, send or receive data, and close the connections gracefully [1].

Errors you are facing may be related to network configurations, firewalls, or incorrect VPN setups and not necessarily the syntax or execution of ObjectScript commands. The network team may need to investigate connection-specific issues on the firewall or VPN [1].

Sources:

0
Robert Cemper · Jun 25

Assuming you have full access to your Windows you may take this approach.

  • install TCPTRACE as a local forward
  • it shows you what it gets from Caché
  • and passes it along to your target system
  • you can be sure it knows the network mechanics
  • if you see your text, but no reply you most likely
  • are a victim of Windows firewalls
    • OUTGOING on your end,
    • INCOMING at the target system
    • OUTGOING for the target reply
    • INCOMING from the target on your side
  • So in the worst case, you need 4 explicit rules ! 
  • Adding TCPTRACE on the target system also improves insight on the other end
0
Stuart Strickland  Jun 27 to Robert Cemper

Thanks Robert, unfortunately TCPTRACE is not installed and I'm not at liberty to do that because it's a client site and they have their own network admin who should be fixing this stuff. We've got the connection working but it's intermittent. I'll suggest TCPTRACE at the next meeting.

0
Robert Cemper  Jun 27 to Stuart Strickland

A possible escape from that trap could be to use a dedicated box
That just runs TCPTRACE
So the message runs CLIENT -> BOX -> SERVER -> BOX -> CLIENT

Of course, a qualified network manager might use Wireshark for this issue
 

0