I am trying to use netcat as a very slim xinetd; but...

[Sam Habiel]

I want to run some TCP program against VISTA that normally goes through xinetd but not using xinetd; but using something I can invoke on the command line as a normal user.

mkfifo foo
nc -l 2600 0<foo | mumps -run GTMLNX^XOBVTCP 1>foo

I know the VISTA protocols pretty well. From Wireshark, I figured that what's most likely breaking the client that connects to 2600 is the fact that VISTA sends 0x0a and 0x0c at the end of the message which don't belong to it. The only acceptable end of message in the VISTA world more or less is 0x04.

I compared this against the packets coming back from the xinetd port, which all end with 0x04.

I was running up and down thinking it's a netcat problem, until I did an strace on GT.M: it was the one sending the extra characters.

Here's the output from strace (I am sure that this is GT.M's trace... it reads the writes to globals in the same trace).

write(1, "</Detail>", 9) = 9
write(1, "</Fault>", 8) = 8
write(1, "</VistaLink>", 12) = 12
write(1, "\4", 1) = 1 <--- Correct
write(1, "\n", 1) = 1 <--- No
write(1, "\f", 1) = 1 <--- No
write(1, "\n", 1) = 1 <--- No

I think GT.M is thinking it's on the command line, perhaps?

Is there a way to convince GT.M that it's something like xinetd connecting?

--Sam H (Sometimes a programmer)

[arthur]

Hello Sam,

Have you looked at gym-unix prog manual on tcp options ?

and

The WRITE command transfers a character stream specified by its arguments to the current device.
The format of the WRITE command is:
W[RITE][:tvexpr] expr|*intexpr|fcc[,...]
● The optional truth-valued expression immediately following the command is a command postconditional that controls whether or not GT.M executes the command.
● An expression argument supplies the text of a WRITE.
● When a WRITE argument consists of a leading asterisk (*) followed by an integer expression, WRITE outputs one character associated with the ASCII code specified by the integer evaluation of the expression.
● WRITE also accepts format control characters as arguments; format control characters modify the position of a virtual cursor: an exclamation point (!) produces the device specific record terminator (for example, new line for a terminal), a number sign (#) produces device specific page terminator (for example, form feed for a terminal) and a question mark (?) followed by an expression moves the virtual cursor to the column specified by the integer evaluation of the expression if the virtual cursor is to the "left" of the specified column.
● When directed to a device bound to a mnemonicspace, WRITE also accepts controlmnemonics, which are keywords specific to the binding – they are delimited by a slash (/) prefix and optionally followed by a parenthetical list of arguments. The parentheses "( )" are optional when there are no arguments, but must appear even if there is a single argument

I do not have time to test this solution though


arthur mumps/vavista newby

[OldMster]

Sam,
This may be the same issue I had some time ago with GT.M and sockets. It insisted on sending a linux line terminator ($c(10)) after every write. The only way I found to stop it was to open the device as a fixed length device with a length of 1.

Mark

[K.S. Bhaskar]

Sam, which GT.M version? Thanks.

Regards
-- Bhaskar

[OldMster]

I went back to my old notes to double check, and the problem I had was writing to files, not sockets. But, since you are starting from the command line it may be a similar problem.
Mark

[K.S. Bhaskar]

On Thursday, October 30, 2014 10:38:09 AM UTC-4, K.S. Bhaskar wrote:

Also, can you share what you are trying to accomplish, rather than how you are trying to accomplish it?

Regards
-- Bhaskar

[Sam Habiel]

Thanks Bhaskar.

GTM>W $ZV
GT.M V6.1-000 Linux x86_64

I have this server on xinetd:
service foia201303_9205_VL
{
port = 9205
socket_type = stream
protocol = tcp
user = sakura
server = /var2/local/foia201303-2/xinetd-VL.sh
type = UNLISTED
wait = no
disable = no
groups = yes
}

Which invokes this:
sakura@icarus:/var2/local/foia201303-2$ cat /var2/local/foia201303-2/xinetd-VL.sh
#!/bin/bash

cd `dirname $0`
. env.foia
date >> broker.log
$gtm_dist/mumps -run GTMLNX^XOBVTCP 2>>broker.log
exit 0

What I am trying to do is to bypass xinetd and just use netcat, which directly invokes GTMLNX^XOBVTCP; it's just lower set-up overhead. The netcat example above actually succeeds in returning a correct response from VISTA, except that VISTA's response has LF and FF in it at the end, which is not sent by xinetd. That tells me that the concept may work.

Arthur, the program already works out of the box with xinetd. I don't want to chanage it.

--Sam

[K.S. Bhaskar]

Sam --

Why not just have a MUMPS process listening at port 9205 for an incoming connection?

Regards
-- Bhaskar

[Sam Habiel]

Yes, certainly, I can do that. But I just wanted to see *if* I can use netcat instead of XinetD.

Sam

[K.S. Bhaskar]

With netcat, $PRINCIPAL is a pipe, and GT.M treats it as such. If the software expects a TCP/IP $PRINCIPAL, there's a bit of mismatch to be corrected.

Regards
-- Bhaskar