Job communication

[Giorgio Garabello]

I would like to communicate two programs that reside on two different machines
Using QPC2 and IPNET.
One solution might be to write on a shared file, but this could create security issues as the file may be opened or deleted from the outside.
Do you think of other solutions?

Thanks in advance to everyone

Giorgio

[tofro]

On the "real black box" with Toolkit 2 and QLib Toolkit (or some other "Pipe support" TK), you could use a named PIPE device on one of the networked QLs, like

Code: Select all

OPEN #3,NET2_PIPE_pnam_1024 : REMark NET2_ is the remote QPC here

Assuming the IPNET server (that I have always wanted to give a try, but never managed to...) works the same as the TK2 NET server, you could use something similar. SMSQ/E already supports named pipes without an additional TK.

I wouldn't worry about security issues with shared media - All the worrying doesn't really help much on a networked QL

Tobias

[Giorgio Garabello]

On the "real black box" with Toolkit 2 and QLib Toolkit (or some other "Pipe support" TK), you could use a named PIPE device on one of the networked QLs, like

Code: Select all

OPEN #3,NET2_PIPE_pnam_1024 : REMark NET2_ is the remote QPC here

Assuming the IPNET server (that I have always wanted to give a try, but never managed to...) works the same as the TK2 NET server, you could use something similar. SMSQ/E already supports named pipes without an additional TK.

Can you tell me something more about these tubes? I do not know anything.
Where can I find information?

[tofro]

Giorgio,

a PIPE is a direct communication channel between two jobs (or inside one job) on the QL. A named pipe on SMSQ/E has a name and can be read and written to by various jobs.

You simply open the same PIPE from two independent jobs and they can simply exchange data through memory instead of through the file system

In one SBASIC job, do:

Code: Select all

OPEN#4, PIPE_testpipe_1024
INPUT #4,a$
PRINT a$

Code: Select all

OPEN #4, PIPE_testpipe_1024
PRINT#4, "Hello, world"&CHR$(10)

Note the reading end must be established and have opened the pipe before you try to write to the writing end.

Should transfer the string "Hello, world" from one job to the other.

The PIPE device is explained in the S*BASIC manual

Tobias

[Giorgio Garabello]

Many thanks!
i will do some test!

[Giorgio Garabello]

Thanks Tobias, it ork well!
Now something more difficult... i need a timeout for the input......but the INPUT command don't allow this..

[tofro]

Thanks Tobias, it ork well!
Now something more difficult... i need a timeout for the input......but the INPUT command don't allow this..

That's actually one of the shortcomings of S*Basic. There is no original S*Basic command, nor, as far as I know, a toolkit command that would be the equivalent of an IO.FSTRG (return as many bytes as available to a buffer or string variable, with an optional timeout).

- INPUT waits for a newline and will never return if there is none
- INKEY$ (which would support a timeout), GET and BGET are single-bytes only

The simplest way to achieve what you want is INKEY$ in a loop, although that is much less efficient than a proper IO.FSTRG call would be.

A bit less simple, but much better, would be the QTRAP command from DIY toolkit Volume T that allows you to directly call the IO.FSTRG Trap from basic.

Tobias

[Martin_Head]

On the "real black box" with Toolkit 2 and QLib Toolkit (or some other "Pipe support" TK), you could use a named PIPE device on one of the networked QLs, like

Code: Select all

OPEN #3,NET2_PIPE_pnam_1024 : REMark NET2_ is the remote QPC here

Assuming the IPNET server (that I have always wanted to give a try, but never managed to...) works the same as the TK2 NET server, you could use something similar. SMSQ/E already supports named pipes without an additional TK.

I wouldn't worry about security issues with shared media - All the worrying doesn't really help much on a networked QL

Tobias

I've never tried this on my driver. But would you not have a problem with the sending NET device buffering the data to be sent, until there is 256 bytes to send, or the channel is closed. Also in your example it should be a NETI, or a NETO device.

It might be better to use FSERVE. Then you could OPEN#3,n2_PIPE_pnam_1024

The pipe would be created on the remote QPC, and if you have any buffering problems you could use FLUSH#3 to force emptying the network buffers.

While we are on the subject of IPNet. I am working on an update after an inquiry from Giorgio. I am trying to combine the IPNet and IPLocalNet files into one program file (if it works). And I am adding some functions that allow you to read the IP address and network station numbers entered when the driver was started. Also a function to read the redirections set up in the NFS_USE command. I am also thinking about a command that allows you to alter individual redirections that have been set in the NFS_USE command. (The NFS_USE command is a bit long, and if you want to change anything, you have to reset everything)

Are there any other requests for changes/features to my driver? I have thought about a function to read the IP port numbers used by the driver, would anyone actually want or have a need for that?

[Giorgio Garabello]

On the "real black box" with Toolkit 2 and QLib Toolkit (or some other "Pipe support" TK), you could use a named PIPE device on one of the networked QLs, like

Code: Select all

OPEN #3,NET2_PIPE_pnam_1024 : REMark NET2_ is the remote QPC here

Assuming the IPNET server (that I have always wanted to give a try, but never managed to...) works the same as the TK2 NET server, you could use something similar. SMSQ/E already supports named pipes without an additional TK.

I wouldn't worry about security issues with shared media - All the worrying doesn't really help much on a networked QL

Tobias

I've never tried this on my driver. But would you not have a problem with the sending NET device buffering the data to be sent, until there is 256 bytes to send, or the channel is closed. Also in your example it should be a NETI, or a NETO device.

It might be better to use FSERVE. Then you could OPEN#3,n2_PIPE_pnam_1024

The pipe would be created on the remote QPC, and if you have any buffering problems you could use FLUSH#3 to force emptying the network buffers.

While we are on the subject of IPNet. I am working on an update after an inquiry from Giorgio. I am trying to combine the IPNet and IPLocalNet files into one program file (if it works). And I am adding some functions that allow you to read the IP address and network station numbers entered when the driver was started. Also a function to read the redirections set up in the NFS_USE command. I am also thinking about a command that allows you to alter individual redirections that have been set in the NFS_USE command. (The NFS_USE command is a bit long, and if you want to change anything, you have to reset everything)

Are there any other requests for changes/features to my driver? I have thought about a function to read the IP port numbers used by the driver, would anyone actually want or have a need for that?

Since you're asking ...: D
- Fserve and Naserve should have different jobname.
- A function that returns the type of loaded server
- Extend the MAP command to any station number, and not just to the top 8, It is not strictly necessary but may be useful in some cases.

[Martin_Head]

Since you're asking ...: D
- Fserve and Naserve should have different jobname.
- A function that returns the type of loaded server
- Extend the MAP command to any station number, and not just to the top 8, It is not strictly necessary but may be useful in some cases.

First one - I will have a look at it.. I think I considered it when I did the NAS server, And kind of decided it seemed like a lot hoops for the program to jump through. And you can only have one of them running.

Second one - I might be able to do that. If I remember correctly, the server type is held in one of the registers of the job. So I would have to find the job, then extract the value in the register.

Third one - I think your kind of stuck at 8. The reason is that the Nx device that the MAP command is for, Is a directory device like mdv/flp etc. And can only use 1-8.
It's a limitation of the QL Network driver that you can only have 8 servers running. Although I think you might be able to extend that in my driver with a bit of lateral thinking.