Job communication
- Giorgio Garabello
- Gold Card
- Posts: 277
- Joined: Tue Jun 30, 2015 8:39 am
- Location: Turin, Italy
- Contact:
Job communication
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
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
Quantum Technology
http://www.hunggartorino.it/ql/language/en/
http://www.hunggartorino.it/ql/language/en/
Re: Job communication
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
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
Code: Select all
OPEN #3,NET2_PIPE_pnam_1024 : REMark NET2_ is the remote QPC here
I wouldn't worry about security issues with shared media - All the worrying doesn't really help much on a networked QL
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
- Giorgio Garabello
- Gold Card
- Posts: 277
- Joined: Tue Jun 30, 2015 8:39 am
- Location: Turin, Italy
- Contact:
Re: Job communication
Can you tell me something more about these tubes? I do not know anything.tofro wrote: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
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.Code: Select all
OPEN #3,NET2_PIPE_pnam_1024 : REMark NET2_ is the remote QPC here
Where can I find information?
Quantum Technology
http://www.hunggartorino.it/ql/language/en/
http://www.hunggartorino.it/ql/language/en/
Re: Job communication
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:
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
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)
Should transfer the string "Hello, world" from one job to the other.
The PIPE device is explained in the S*BASIC manual
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
- Giorgio Garabello
- Gold Card
- Posts: 277
- Joined: Tue Jun 30, 2015 8:39 am
- Location: Turin, Italy
- Contact:
Re: Job communication
Many thanks!
i will do some test!
i will do some test!
Quantum Technology
http://www.hunggartorino.it/ql/language/en/
http://www.hunggartorino.it/ql/language/en/
- Giorgio Garabello
- Gold Card
- Posts: 277
- Joined: Tue Jun 30, 2015 8:39 am
- Location: Turin, Italy
- Contact:
Re: Job communication
Thanks Tobias, it ork well!
Now something more difficult... i need a timeout for the input......but the INPUT command don't allow this..
Now something more difficult... i need a timeout for the input......but the INPUT command don't allow this..
Quantum Technology
http://www.hunggartorino.it/ql/language/en/
http://www.hunggartorino.it/ql/language/en/
Re: Job communication
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).Giorgio Garabello wrote:Thanks Tobias, it ork well!
Now something more difficult... i need a timeout for the input......but the INPUT command don't allow this..
- 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
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Aurora
- Posts: 852
- Joined: Tue Dec 17, 2013 1:17 pm
Re: Job communication
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.tofro wrote: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
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.Code: Select all
OPEN #3,NET2_PIPE_pnam_1024 : REMark NET2_ is the remote QPC here
I wouldn't worry about security issues with shared media - All the worrying doesn't really help much on a networked QL
Tobias
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
- Gold Card
- Posts: 277
- Joined: Tue Jun 30, 2015 8:39 am
- Location: Turin, Italy
- Contact:
Re: Job communication
Since you're asking ...: DMartin_Head wrote: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.tofro wrote: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
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.Code: Select all
OPEN #3,NET2_PIPE_pnam_1024 : REMark NET2_ is the remote QPC here
I wouldn't worry about security issues with shared media - All the worrying doesn't really help much on a networked QL
Tobias
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?
- 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.
Quantum Technology
http://www.hunggartorino.it/ql/language/en/
http://www.hunggartorino.it/ql/language/en/
-
- Aurora
- Posts: 852
- Joined: Tue Dec 17, 2013 1:17 pm
Re: Job communication
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.Giorgio Garabello wrote: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.
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.