Laden...

TcpListener.Start() Verhalten in Docker

Erstellt von Papst vor 3 Jahren Letzter Beitrag vor 3 Jahren 1.563 Views
P
Papst Themenstarter:in
441 Beiträge seit 2014
vor 3 Jahren
TcpListener.Start() Verhalten in Docker

Hallo zusammen,

ich bin aktuell etwas ratlos, vielleicht hat das einer von euch schon einmal ähnlich erlebt.
Ich habe eine Applikation, die im untersten Level für den Transport einen TcpListener verwendet um einen Server zu stellen.

Dabei habe ich ein klassisches Works on my machine Problem:
Ich rufe TcpListener.Start() auf, das läuft im Debug oder in Release auf der Entwicklungsmaschine sauber durch und er baut danach den Server auf.
Lasse ich das ganze als Docker paketieren und auf der gleichen Maschine in einem Container laufen, blockiert er in der Ausführung innerhalb des .Start() aufrufes (also lange vor einem AcceptClient, dass innerhalb der Anwendungsschicht in einer Lib läuft)... sonst haben andere Entwickler immer nur bei AcceptClient die Probleme 😃

VG
Papst

6.911 Beiträge seit 2009
vor 3 Jahren

Hallo Papst,

direkt zum Problem kann ich dir leider nicht helfen, aber wegen

im untersten Level für den Transport einen Tcp

der Hinweis dass dazu auch Kestrel verwendet werden kann. Somit kannst du dich mehr um die Anwendung kümmern, da die Infrastruktur von ASP.NET Core geliefert wird.
Ein Beispiel dazu siehst du in MultiProtocolAspNetCore.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

P
Papst Themenstarter:in
441 Beiträge seit 2014
vor 3 Jahren

Hi,

das mit Kestrel kenne ich tatsächlich. Ich verwende allerdings einen fertigen Protokollstack, der auf TcpListener aufbaut.
Die Option wäre dafür gewesen entweder einen Interop Layer oder einen eigenen Protokollstack zu entwickeln (bzw. zu der Lib beitragen).
Es handelt sich dabei um Modbus/TCP mit der Lib NModbus.

Vorhin kam mir noch die Idee, dass ein Problem des OS sein könnte.. dass ich auf Linux (--> im Container) mit einem normalen Prozess nicht den Port öffnen darf.

16.807 Beiträge seit 2008
vor 3 Jahren

War gerade neugierig, ob das wirklich sein kann - und ich konnte mit dem TcpListener im Docker Container erfolgreich eine Verbindung aufbauen.

Am TcpListener selbst wirds also nicht liegen.

T
2.219 Beiträge seit 2008
vor 3 Jahren

Hätte mich auch überrascht, da dort nur der interne Socket an die IP gebunden wird.
Hast du mal geschaut ob Docker irgendwelche Logs schreibt bzw. ob im Container irgendwelche Meldungen auftauchen?

Klingt erstmal danach als würde er eben beim Socket Binding irgendwo hängen bleiben.
Kann also auch irgend eine Konstellation mit Docker sein, sollte man zu mindest in betracht ziehen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 3 Jahren

da dort nur der interne Socket an die IP gebunden wird.

Und genau das könnte durchaus zu einem blockierenden Verhalten führen; vor allem da man innerhalb eines Containers keine fixe IP bindet, sondern Any.

P
Papst Themenstarter:in
441 Beiträge seit 2014
vor 3 Jahren

Problem noch nicht gefunden, aber zumindest eine Lösung. Highports funktionieren.

Es scheint also eine Limitierung zu sein, dass der Kernel/OS (so genau kenne ich mich, vor allem bei Linux, in den Schichten nicht so aus) das Socket öffnen verhindert.
Interessanterweise gibt es keine Exception.

Die Docker Logs geben leider nur die Logausgaben der eigenen Software her, von dort habe ich schon den genauen Punkt (also .Start()) herausgefunden.

Der Server im Container horcht jetzt auf 105021502, das wird dann von Docker auf 502 gemapped. Funktioniert.

16.807 Beiträge seit 2008
vor 3 Jahren

Ports unterhalb von 1024 sind reserviert und können i.d.R. nicht ohne Adminrechte gemappt werden.
Best Practise ist es sich einen Port Range für seine Services für innerhalb und ausserhalb des Clusters zu definieren.

P
Papst Themenstarter:in
441 Beiträge seit 2014
vor 3 Jahren

Richtig, ich bin eigentlich davon ausgegangen, diese Beschränkung im Container nicht zu haben (warum auch immer ich auf diese Idee kam - vermutlich, weil Kestrel problemlos Port 80 öffnen kann 😃 ) und wurde eines besseren belehrt.