Virtual serial port between docker containers
I can create two linked virtual serial ports on a Linux system with socat, and pretend one end is a serial device, and the other one is some code that uses the device. The socat command would look like:
socat -d -d pty,raw,echo=1 pty,raw,echo=0
And it creates two ports on the system, e.g. /dev/pts/3 and /dev/pts/4.
Now, I want to go one step further, and have two docker containers representing the system: one container pretending to be the serial device, and the other container being the code using that device. The goal being that when in production, I can remove the virtual device container and just use the real sensor.
The problem is that I can't seem to find a way to share the devpts between two containers, and somehow it feels like it is not something good to do.
Would there be a way to achieve the exact same behavior (virtual serial ports) by using named pipes instead of pty? Then I could share the file (say "/home/user/folder/my_pipe") between the containers (actually I would mount "/home/user/folder" on both, and both would then access my_pipe).
Or is there another, better way to do all that with docker?
pipe docker serial-port socat pty
asked Dec 17 at 13:53
JonesV
1401315
add a comment |
I can create two linked virtual serial ports on a Linux system with socat, and pretend one end is a serial device, and the other one is some code that uses the device. The socat command would look like:
socat -d -d pty,raw,echo=1 pty,raw,echo=0
And it creates two ports on the system, e.g. /dev/pts/3 and /dev/pts/4.
Now, I want to go one step further, and have two docker containers representing the system: one container pretending to be the serial device, and the other container being the code using that device. The goal being that when in production, I can remove the virtual device container and just use the real sensor.
The problem is that I can't seem to find a way to share the devpts between two containers, and somehow it feels like it is not something good to do.
Would there be a way to achieve the exact same behavior (virtual serial ports) by using named pipes instead of pty? Then I could share the file (say "/home/user/folder/my_pipe") between the containers (actually I would mount "/home/user/folder" on both, and both would then access my_pipe).
Or is there another, better way to do all that with docker?
pipe docker serial-port socat pty
asked Dec 17 at 13:53
JonesV
1401315
1
cansocatwork across the network?
– ctrl-alt-delor
Dec 17 at 14:03
Good question. Ideally, I want the "code container" to think that it is connected to a serial device. If I changed the code to use a network source instead of a serial one, then that would not be a simulation of the sensor anymore, would it? :-)
– JonesV
Dec 17 at 15:07
1
I am thinking that you create two virtual serial ports, connected via the network.
– ctrl-alt-delor
Dec 17 at 15:34
Right, that sounds interesting. Still, the "code container" has to know that and create it's own virtual serial port. Ideally I would not want it to know about that. Maybe that's not possible, in which case I would just put everything in the same container, and have a CMD argument to enable simulation :-/
– JonesV
Dec 17 at 15:39
add a comment |
I can create two linked virtual serial ports on a Linux system with socat, and pretend one end is a serial device, and the other one is some code that uses the device. The socat command would look like:
socat -d -d pty,raw,echo=1 pty,raw,echo=0
And it creates two ports on the system, e.g. /dev/pts/3 and /dev/pts/4.
Now, I want to go one step further, and have two docker containers representing the system: one container pretending to be the serial device, and the other container being the code using that device. The goal being that when in production, I can remove the virtual device container and just use the real sensor.
The problem is that I can't seem to find a way to share the devpts between two containers, and somehow it feels like it is not something good to do.
Would there be a way to achieve the exact same behavior (virtual serial ports) by using named pipes instead of pty? Then I could share the file (say "/home/user/folder/my_pipe") between the containers (actually I would mount "/home/user/folder" on both, and both would then access my_pipe).
Or is there another, better way to do all that with docker?
pipe docker serial-port socat pty
asked Dec 17 at 13:53
JonesV
1401315
I can create two linked virtual serial ports on a Linux system with socat, and pretend one end is a serial device, and the other one is some code that uses the device. The socat command would look like:
socat -d -d pty,raw,echo=1 pty,raw,echo=0
And it creates two ports on the system, e.g. /dev/pts/3 and /dev/pts/4.
Now, I want to go one step further, and have two docker containers representing the system: one container pretending to be the serial device, and the other container being the code using that device. The goal being that when in production, I can remove the virtual device container and just use the real sensor.
The problem is that I can't seem to find a way to share the devpts between two containers, and somehow it feels like it is not something good to do.
Would there be a way to achieve the exact same behavior (virtual serial ports) by using named pipes instead of pty? Then I could share the file (say "/home/user/folder/my_pipe") between the containers (actually I would mount "/home/user/folder" on both, and both would then access my_pipe).
Or is there another, better way to do all that with docker?
pipe docker serial-port socat pty
pipe docker serial-port socat pty
asked Dec 17 at 13:53
JonesV
1401315
asked Dec 17 at 13:53
JonesV
1401315
asked Dec 17 at 13:53
JonesV
1401315
asked Dec 17 at 13:53
JonesV
1401315
asked Dec 17 at 13:53
JonesV
1401315
1401315
1
cansocatwork across the network?
– ctrl-alt-delor
Dec 17 at 14:03
Good question. Ideally, I want the "code container" to think that it is connected to a serial device. If I changed the code to use a network source instead of a serial one, then that would not be a simulation of the sensor anymore, would it? :-)
– JonesV
Dec 17 at 15:07
1
I am thinking that you create two virtual serial ports, connected via the network.
– ctrl-alt-delor
Dec 17 at 15:34
Right, that sounds interesting. Still, the "code container" has to know that and create it's own virtual serial port. Ideally I would not want it to know about that. Maybe that's not possible, in which case I would just put everything in the same container, and have a CMD argument to enable simulation :-/
– JonesV
Dec 17 at 15:39
add a comment |
1
cansocatwork across the network?
– ctrl-alt-delor
Dec 17 at 14:03
Good question. Ideally, I want the "code container" to think that it is connected to a serial device. If I changed the code to use a network source instead of a serial one, then that would not be a simulation of the sensor anymore, would it? :-)
– JonesV
Dec 17 at 15:07
1
I am thinking that you create two virtual serial ports, connected via the network.
– ctrl-alt-delor
Dec 17 at 15:34
Right, that sounds interesting. Still, the "code container" has to know that and create it's own virtual serial port. Ideally I would not want it to know about that. Maybe that's not possible, in which case I would just put everything in the same container, and have a CMD argument to enable simulation :-/
– JonesV
Dec 17 at 15:39
1
1
can
socat work across the network?– ctrl-alt-delor
Dec 17 at 14:03
can
socat work across the network?– ctrl-alt-delor
Dec 17 at 14:03
Good question. Ideally, I want the "code container" to think that it is connected to a serial device. If I changed the code to use a network source instead of a serial one, then that would not be a simulation of the sensor anymore, would it? :-)
– JonesV
Dec 17 at 15:07
Good question. Ideally, I want the "code container" to think that it is connected to a serial device. If I changed the code to use a network source instead of a serial one, then that would not be a simulation of the sensor anymore, would it? :-)
– JonesV
Dec 17 at 15:07
1
1
I am thinking that you create two virtual serial ports, connected via the network.
– ctrl-alt-delor
Dec 17 at 15:34
I am thinking that you create two virtual serial ports, connected via the network.
– ctrl-alt-delor
Dec 17 at 15:34
Right, that sounds interesting. Still, the "code container" has to know that and create it's own virtual serial port. Ideally I would not want it to know about that. Maybe that's not possible, in which case I would just put everything in the same container, and have a CMD argument to enable simulation :-/
– JonesV
Dec 17 at 15:39
Right, that sounds interesting. Still, the "code container" has to know that and create it's own virtual serial port. Ideally I would not want it to know about that. Maybe that's not possible, in which case I would just put everything in the same container, and have a CMD argument to enable simulation :-/
– JonesV
Dec 17 at 15:39
add a comment |
1 Answer
1
active
oldest
votes
(BTW, "virtual serial port" is a Windows term, on Unix these things are called "(pseudo) tty".)
What ctrl-alt-delor means is that you can just do one socat in the "serial device container", and one socat in the "code container" using the device; they communicate via a network connection, so one container has to know the IP address and port of the other container, and that's it (and you can choose which container connects to the other container). Also, the code running in the "code container" just uses the tty; so it doesn't depend on anything else except the path of the tty (which should be a parameter/commandline argument/etc., anyway).
Details of the socat call depend on some other details of what you want to do; maybe using tcp-listen and tcp is the simplest variant. Plenty of socat examples are e.g. here.
Edit
To explain the naming: A tty (teletype) is an abstraction over certain serial port parameters, together with a translation and interpretation of of characters (like end-of-line), and other things like the line discipline. A pseudo-tty is a tty without real hardware. A tty differs from a file in that it allows ioctls to set all these parameters.
So if your program has a feature to set, say, baud rate, you need a tty. If it doesn't, you could also use a named pipe.
However, it makes no difference if you use a named pipe or a tty with respect to sharing between containers: You'd still have to set up a common filesystem somewhere, where you can put either of them. And that's not necessarily how (docker) containers typically work.
OTOH, (docker) containers are usually ready for networking. So it might just be simpler to connect the containers via networking, instead of getting them to have a shared filesystems. And it has the additional advantage that the containers need not run on the same host (which docker containers don't assume). So it's a more natural fit.
You can do it any way you like, of course.
answered Dec 18 at 8:43
dirkt
16.6k21335
Interesting point about the naming. Does that mean that you cannot simulate a serial link other than through a (pseudo) tty? I guess part of the question was that: if I could make that through an arbitrary file, I could share that file between both containers.
– JonesV
Dec 18 at 9:52
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489478%2fvirtual-serial-port-between-docker-containers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
(BTW, "virtual serial port" is a Windows term, on Unix these things are called "(pseudo) tty".)
What ctrl-alt-delor means is that you can just do one socat in the "serial device container", and one socat in the "code container" using the device; they communicate via a network connection, so one container has to know the IP address and port of the other container, and that's it (and you can choose which container connects to the other container). Also, the code running in the "code container" just uses the tty; so it doesn't depend on anything else except the path of the tty (which should be a parameter/commandline argument/etc., anyway).
Details of the socat call depend on some other details of what you want to do; maybe using tcp-listen and tcp is the simplest variant. Plenty of socat examples are e.g. here.
Edit
To explain the naming: A tty (teletype) is an abstraction over certain serial port parameters, together with a translation and interpretation of of characters (like end-of-line), and other things like the line discipline. A pseudo-tty is a tty without real hardware. A tty differs from a file in that it allows ioctls to set all these parameters.
So if your program has a feature to set, say, baud rate, you need a tty. If it doesn't, you could also use a named pipe.
However, it makes no difference if you use a named pipe or a tty with respect to sharing between containers: You'd still have to set up a common filesystem somewhere, where you can put either of them. And that's not necessarily how (docker) containers typically work.
OTOH, (docker) containers are usually ready for networking. So it might just be simpler to connect the containers via networking, instead of getting them to have a shared filesystems. And it has the additional advantage that the containers need not run on the same host (which docker containers don't assume). So it's a more natural fit.
You can do it any way you like, of course.
answered Dec 18 at 8:43
dirkt
16.6k21335
Interesting point about the naming. Does that mean that you cannot simulate a serial link other than through a (pseudo) tty? I guess part of the question was that: if I could make that through an arbitrary file, I could share that file between both containers.
– JonesV
Dec 18 at 9:52
add a comment |
(BTW, "virtual serial port" is a Windows term, on Unix these things are called "(pseudo) tty".)
What ctrl-alt-delor means is that you can just do one socat in the "serial device container", and one socat in the "code container" using the device; they communicate via a network connection, so one container has to know the IP address and port of the other container, and that's it (and you can choose which container connects to the other container). Also, the code running in the "code container" just uses the tty; so it doesn't depend on anything else except the path of the tty (which should be a parameter/commandline argument/etc., anyway).
Details of the socat call depend on some other details of what you want to do; maybe using tcp-listen and tcp is the simplest variant. Plenty of socat examples are e.g. here.
Edit
To explain the naming: A tty (teletype) is an abstraction over certain serial port parameters, together with a translation and interpretation of of characters (like end-of-line), and other things like the line discipline. A pseudo-tty is a tty without real hardware. A tty differs from a file in that it allows ioctls to set all these parameters.
So if your program has a feature to set, say, baud rate, you need a tty. If it doesn't, you could also use a named pipe.
However, it makes no difference if you use a named pipe or a tty with respect to sharing between containers: You'd still have to set up a common filesystem somewhere, where you can put either of them. And that's not necessarily how (docker) containers typically work.
OTOH, (docker) containers are usually ready for networking. So it might just be simpler to connect the containers via networking, instead of getting them to have a shared filesystems. And it has the additional advantage that the containers need not run on the same host (which docker containers don't assume). So it's a more natural fit.
You can do it any way you like, of course.
answered Dec 18 at 8:43
dirkt
16.6k21335
Interesting point about the naming. Does that mean that you cannot simulate a serial link other than through a (pseudo) tty? I guess part of the question was that: if I could make that through an arbitrary file, I could share that file between both containers.
– JonesV
Dec 18 at 9:52
add a comment |
(BTW, "virtual serial port" is a Windows term, on Unix these things are called "(pseudo) tty".)
What ctrl-alt-delor means is that you can just do one socat in the "serial device container", and one socat in the "code container" using the device; they communicate via a network connection, so one container has to know the IP address and port of the other container, and that's it (and you can choose which container connects to the other container). Also, the code running in the "code container" just uses the tty; so it doesn't depend on anything else except the path of the tty (which should be a parameter/commandline argument/etc., anyway).
Details of the socat call depend on some other details of what you want to do; maybe using tcp-listen and tcp is the simplest variant. Plenty of socat examples are e.g. here.
Edit
To explain the naming: A tty (teletype) is an abstraction over certain serial port parameters, together with a translation and interpretation of of characters (like end-of-line), and other things like the line discipline. A pseudo-tty is a tty without real hardware. A tty differs from a file in that it allows ioctls to set all these parameters.
So if your program has a feature to set, say, baud rate, you need a tty. If it doesn't, you could also use a named pipe.
However, it makes no difference if you use a named pipe or a tty with respect to sharing between containers: You'd still have to set up a common filesystem somewhere, where you can put either of them. And that's not necessarily how (docker) containers typically work.
OTOH, (docker) containers are usually ready for networking. So it might just be simpler to connect the containers via networking, instead of getting them to have a shared filesystems. And it has the additional advantage that the containers need not run on the same host (which docker containers don't assume). So it's a more natural fit.
You can do it any way you like, of course.
answered Dec 18 at 8:43
dirkt
16.6k21335
(BTW, "virtual serial port" is a Windows term, on Unix these things are called "(pseudo) tty".)
What ctrl-alt-delor means is that you can just do one socat in the "serial device container", and one socat in the "code container" using the device; they communicate via a network connection, so one container has to know the IP address and port of the other container, and that's it (and you can choose which container connects to the other container). Also, the code running in the "code container" just uses the tty; so it doesn't depend on anything else except the path of the tty (which should be a parameter/commandline argument/etc., anyway).
Details of the socat call depend on some other details of what you want to do; maybe using tcp-listen and tcp is the simplest variant. Plenty of socat examples are e.g. here.
Edit
To explain the naming: A tty (teletype) is an abstraction over certain serial port parameters, together with a translation and interpretation of of characters (like end-of-line), and other things like the line discipline. A pseudo-tty is a tty without real hardware. A tty differs from a file in that it allows ioctls to set all these parameters.
So if your program has a feature to set, say, baud rate, you need a tty. If it doesn't, you could also use a named pipe.
However, it makes no difference if you use a named pipe or a tty with respect to sharing between containers: You'd still have to set up a common filesystem somewhere, where you can put either of them. And that's not necessarily how (docker) containers typically work.
OTOH, (docker) containers are usually ready for networking. So it might just be simpler to connect the containers via networking, instead of getting them to have a shared filesystems. And it has the additional advantage that the containers need not run on the same host (which docker containers don't assume). So it's a more natural fit.
You can do it any way you like, of course.
answered Dec 18 at 8:43
dirkt
16.6k21335
edited Dec 18 at 10:16
answered Dec 18 at 8:43
dirkt
16.6k21335
answered Dec 18 at 8:43
dirkt
16.6k21335
answered Dec 18 at 8:43
dirkt
16.6k21335
16.6k21335
Interesting point about the naming. Does that mean that you cannot simulate a serial link other than through a (pseudo) tty? I guess part of the question was that: if I could make that through an arbitrary file, I could share that file between both containers.
– JonesV
Dec 18 at 9:52
add a comment |
Interesting point about the naming. Does that mean that you cannot simulate a serial link other than through a (pseudo) tty? I guess part of the question was that: if I could make that through an arbitrary file, I could share that file between both containers.
– JonesV
Dec 18 at 9:52
Interesting point about the naming. Does that mean that you cannot simulate a serial link other than through a (pseudo) tty? I guess part of the question was that: if I could make that through an arbitrary file, I could share that file between both containers.
– JonesV
Dec 18 at 9:52
Interesting point about the naming. Does that mean that you cannot simulate a serial link other than through a (pseudo) tty? I guess part of the question was that: if I could make that through an arbitrary file, I could share that file between both containers.
– JonesV
Dec 18 at 9:52
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489478%2fvirtual-serial-port-between-docker-containers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
can
socatwork across the network?– ctrl-alt-delor
Dec 17 at 14:03
Good question. Ideally, I want the "code container" to think that it is connected to a serial device. If I changed the code to use a network source instead of a serial one, then that would not be a simulation of the sensor anymore, would it? :-)
– JonesV
Dec 17 at 15:07
1
I am thinking that you create two virtual serial ports, connected via the network.
– ctrl-alt-delor
Dec 17 at 15:34
Right, that sounds interesting. Still, the "code container" has to know that and create it's own virtual serial port. Ideally I would not want it to know about that. Maybe that's not possible, in which case I would just put everything in the same container, and have a CMD argument to enable simulation :-/
– JonesV
Dec 17 at 15:39