CODEWITHSUNDEEP
linuxwindowsdocker.net-core
Lukas Hieronimus Adler
Lukas Hieronimus Adler

Reputation: 1094

Communication between Windows Host and Linux Docker Container

enter image description hereI have the following problem. I have a piece of software on a windows host system, which emulates the com-interface at this computer. Now i would like to provide a API / Socket / Pipe in this software, which accepts a string which is transfered over LAN.

The submit software should be a .net core webapplication, which is hosted in kubernetes as a docker container (Linux).

Which kind of technology could i use to speak between a Linux Container and a Windows Host.

  1. Named Pipes -> I think they are not available under Linux?
  2. Sockets?
  3. Try to open a webserver on the windows host to get access via http ?

Whats your ideas and why do you prefer a solution?

Upvotes: 4

Views: 1049

Answers (1)

Lie Ryan
Lie Ryan

Reputation: 64923

Linux do have named pipes, though the exact semantic of different operations vary, but the problem you'll have is that named pipe cannot be used to communicate between different systems. Named pipe is an inter-process communication for process running on the same machine. Note that Windows Host and Linux Guest are considered two separate systems here even when they live in the same physical machines.

TCP is the most general purpose form of sockets and is the standard way to connect between two OSes. If you don't know why you want to use the other protocols, TCP is usually a good bet that it'll be able to connect almost everything.

Now the only problem is what application level protocol you want to use, and whether you want to add any security layer (i.e. TLS) to encrypt and authenticate the connection between the machines. If you have a simple service that only needs to transmit simple strings, then you probably can just use TCP/TLS socket directly, but if you want to benefit from standardized phraseology, techniques, and libraries and frameworks for various things like communicating request and responses statuses, authentication, optimistic locking, caching, proxying, session management, arbitrary length stream encoding, etc, then building your communication on top of HTTP/HTTPS is a sensible thing to do. You'll find that a lot of services nowadays are built as a web service as it makes things a lot simpler when you need to scale and make use of those features.

Upvotes: 2

Related Questions