TCP Port x-IP Server Client Modell

Baust du die Clients selbst?

LadyGaga schrieb:
> dafür brauche ich einen Port und Mehrere IP Adressen.

Warum kann man den Client nicht mehrmals auf derselben Maschine starten?

Stefan ⛄ F. schrieb:
> Dirk B. schrieb:
>> Warum kann man den Client nicht mehrmals auf derselben Maschine starten?
>
> Kann man, wenn du bei jedem Client einstellen kannst, an welche IP
> Adresse er gebunden werden soll.
>
> Und wenn der Cient das nicht kann, würde ich ihn in einen Docker
> Container packen. Aber das ist auch schon Linux Spezifisch. Windows ist
> halt nicht für Entwickler gemacht.

Mach ich bei Putty, Firefox und selbstgeschriebenen Clients auch nicht.
Trotzdem sendet der Server die Daten nur an den anfragenden Client.

LadyGaga schrieb:

> ich möchte eine Client Server Modell System Testen,
> ich soll ein Server starten sowie Mehrere Client.
> dafür brauche ich einen Port und Mehrere IP Adressen.

Nein, die brauchst du dafür nicht.


LadyGaga schrieb:
> ja, dazu darf ich keine physikalische Konfiguration durchführen.

Machst du nicht. Brauchst du auch nicht.

> ich denke, ich brauche so zu sagen eine Virtuell Netzwerk.

Das wäre der Fall, wenn du mehrere virtuelle Maschinen hättest. Kannst 
du natürlich machen, aber (du ahnst es bestimmt) brauchst du nicht.


LadyGaga schrieb:
>
> Nach Server start (in c# programiert) der Listner wartet auf eine
> Verbindung mit dem Client.

So funktioniert ein TCP-Server, ja.

> die Clients melden über IP Adresse und Port beim Server.

Nein. Der Server erkennt einen (neuen) Client daran, daß ein Socket 
(neu) geöffnet wird, über den jemand mit ihm redet.

> der Server bearbeitet die Daten und sollte jede Client daten senden.

Ja. Dazu verwendet der Server aber den Socket. Das ist praktisch das 
gleiche, wie ein Filehandle. Nur das man darauf schreiben und davon 
lesen kann.

> er selber erkennt der Clients anhand ihe IP Adresse

Nein. Die IP-Adresse des Clients interessiert den Server zumindest für 
die Kommunikation überhaupt nicht. Er kann sie natürlich abfragen, z.B. 
für ein Logfile.


PS: das ist übrigens das falsche Forum.

Wir haben einige MDE-Clients in der Firma, die tatsächlich über deren IP 
identifiziert werden. Sie verbinden sich mit dem Server alle per HTTPS 
und übermitteln darüber Daten. Das ist ungefähr das, was der TO 
nachbilden will.
Ich hätte das zwar anders gemacht (und zwar dass sich die Clients über 
einen Namen beim Server anmelden), ist aber leider so gekauft worden.

Stefan ⛄ F. schrieb:
> Axel S. schrieb:
>>> er selber erkennt der Clients anhand ihe IP Adresse
>> Nein. Die IP-Adresse des Clients interessiert den Server zumindest für
>> die Kommunikation überhaupt nicht.
>
> Du sprichst vom Betriebssystem.

Ich spreche vom Programm "Server". Ein TCP-Server signalisert seine 
Bereitschaft zur Kommunikation üblicherweise mit listen(2) und nimmt 
eine neue Verbindung mit accept(2) an. Das alles hantiert mit einer 
Datenstruktur namens Socket. Die kann eine IP-Adresse zugeordnet 
haben, muß aber nicht.

> Aber du weißt nicht, was seine Server
> Anwendung mit der IP Adresse macht. Es kommt vor, dass Menschen andere
> Menschen oder Maschinen anhand ihrer vermeintlich eindeutigen IP Adresse
> erkennen wollen.

Kann schon sein. Aber auch dann redet er mit dem Teilnehmer über den 
Socket. Sogar wenn er die Verbindung nur kommentarlos schließt, 
verwendet er den Socket mit close(2).

> Ob das beim TO so Sinn macht, wissen wir nicht. Dafür hat er zu wenige
> Infos herausgerückt.

Natürlich nicht. Seine Frage bezog sich ja auch auf das Netzwerk, das er 
glaubt zum Testen seines Servers zu brauchen. Er braucht aber eigentlich 
nur ein netzwerkfähiges Betriebssystem. Das muß noch nicht mal eine 
Netzwerkkarte (physisch oder virtuell) haben. Das loopback Network 
(127.0.0.1) reicht schon.


Ich empfehle den Buchklassiker von Richard Stevens, "Programmieren von 
Unix-Netzen". Er nutzt zwar WinDOS und C#. Aber die Grundlagen sind die 
gleichen.

Stefan ⛄ F. schrieb:
> Mag sein, aber er will halt jedem Client eine eigene IP Adresse geben.

Mein, will er nicht!
Er Bindet sich an die kombination aus IP und Port
Und Nein! - damit ist nicht die Port-Nummer gemeint, auf der der Server 
lauscht, sondern die, de für die Gegenrichtung ausgehandelt wird.

Harry L. schrieb:
> Stefan ⛄ F. schrieb:
>> Mag sein, aber er will halt jedem Client eine eigene IP Adresse geben.
>
> Mein, will er nicht!

Ich hatte ihn so verstanden. Aber nicht, ob er das aus freien Stücken 
will, oder ob er glaubt, das zu brauchen.

> Er Bindet sich an die kombination aus IP und Port
> Und Nein! - damit ist nicht die Port-Nummer gemeint, auf der der Server
> lauscht, sondern die, de für die Gegenrichtung ausgehandelt wird.

Ja. Aber auf die hat er ja keinen Einfluß. Und er hat die Kombination 
ja schon, wenn sich ein Client verbindet. Der Server muß sich nicht mehr 
separat mit dem Client verbinden. In dem Moment, wenn accept(2) 
zurückkehrt, steht die Verbindung schon.

Axel S. schrieb:
> Ja. Aber auf die hat er ja keinen Einfluß. Und er hat die Kombination
> ja schon, wenn sich ein Client verbindet. Der Server muß sich nicht mehr
> separat mit dem Client verbinden. In dem Moment, wenn accept(2)
> zurückkehrt, steht die Verbindung schon.

Ich habe nichts Gegenteiliges geschrieben...

Das ganze könnte man mit network namespeces, veth pairs, und einer 
bridge realisieren. Zumindest unter linux. Beispiel: (Muss als root 
ausgeführt werden)

1

#!/bin/bash

2

3

# Bridge "br-fake-switch" erstellen. Ist wie ein switch

4

ip link add br-fake-switch type bridge

5

ip link set br-fake-switch up

6

7

# Ein veth pair (ist wie ein kabel), interfaces vm-server und vs-server werden erstellt, was am einen ende rein geht, kommt am andern raus

8

# Dann wird vm-server zur Bridge br-fake-switch hinzugefügt, dann der netzwerk namespace vnet-server erstellt, vs-server da rein verschoben,

9

# und dann noch die IP usw. von den Interfacen im Namespace konfiguriert

10

ip link add vm-server type veth peer vs-server

11

ip link set vm-server master br-fake-switch

12

ip netns add vnet-server

13

ip link set vs-server netns vnet-server

14

ip netns exec vnet-server ip addr add 10.83.5.2/24 dev vs-server

15

ip netns exec vnet-server ip link set lo up

16

ip netns exec vnet-server ip link set vs-server up

17

18

# Nochmal das selbe, für einen weiteren neuen NS

19

ip link add vm-client1 type veth peer vs-client1

20

ip link set vm-client1 master br-fake-switch

21

ip netns add vnet-client1

22

ip link set vs-client1 netns vnet-client1

23

ip netns exec vnet-client1 ip addr add 10.83.5.3/24 dev vs-client1

24

ip netns exec vnet-client1 ip link set lo up

25

ip netns exec vnet-client1 ip link set vs-client1 up

26

27

# Nochmal das selbe, für einen weiteren neuen NS

28

ip link add vm-client2 type veth peer vs-client2

29

ip link set vm-client2 master br-fake-switch

30

ip netns add vnet-client2

31

ip link set vs-client2 netns vnet-client2

32

ip netns exec vnet-client2 ip addr add 10.83.5.4/24 dev vs-client2

33

ip netns exec vnet-client2 ip link set lo up

34

ip netns exec vnet-client2 ip link set vs-client2 up

Mit "ip netns exec [ns] [commando]" kann man Kommandos in einem netns 
ausführen. z.B. "ip netns exec vnet-server bash", dann hat man ne bash 
session in der netns, und alle Kommandos die man da eingibt sind in dem 
netns. "ip netns exec" braucht zwar auch root (zumindest in diesem 
speziellen fall, es gibt ausnahmen), aber man kann danach mit "su - 
username" wieder zu einem user wechseln.

Zum illustrieren, wie das Netzwerk aus Sicht der diversen NS aussieht:

1

root@phenix:~# brctl show

2

bridge name  bridge id    STP enabled  interfaces

3

br-fake-switch    8000.0edc7e8e6272  no    vm-client1

4

              vm-client2

5

              vm-server

6

root@phenix:~# ip addr show up

7

...

8

6: br-fake-switch: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000

9

    link/ether 0e:dc:7e:8e:62:72 brd ff:ff:ff:ff:ff:ff

10

    inet6 fe80::2c0d:63ff:fe3f:ccb7/64 scope link 

11

       valid_lft forever preferred_lft forever

12

8: vm-server@if7: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-fake-switch state LOWERLAYERDOWN group default qlen 1000

13

    link/ether e2:19:42:66:84:95 brd ff:ff:ff:ff:ff:ff link-netns vnet-server

14

10: vm-client1@if9: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-fake-switch state LOWERLAYERDOWN group default qlen 1000

15

    link/ether 0e:dc:7e:8e:62:72 brd ff:ff:ff:ff:ff:ff link-netns vnet-client1

16

12: vm-client2@if11: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-fake-switch state LOWERLAYERDOWN group default qlen 1000

17

    link/ether 12:50:9c:d9:f8:1e brd ff:ff:ff:ff:ff:ff link-netns vnet-client2

18

19

root@phenix:~# ip netns exec vnet-server ip addr show up

20

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

21

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

22

    inet 127.0.0.1/8 scope host lo

23

       valid_lft forever preferred_lft forever

24

    inet6 ::1/128 scope host 

25

       valid_lft forever preferred_lft forever

26

7: vs-server@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

27

    link/ether 12:71:82:95:c7:62 brd ff:ff:ff:ff:ff:ff link-netnsid 0

28

    inet 10.83.5.2/24 scope global vs-server

29

       valid_lft forever preferred_lft forever

30

    inet6 fe80::1071:82ff:fe95:c762/64 scope link 

31

       valid_lft forever preferred_lft forever

32

33

root@phenix:~# ip netns exec vnet-client1 ip addr show up

34

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

35

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

36

    inet 127.0.0.1/8 scope host lo

37

       valid_lft forever preferred_lft forever

38

    inet6 ::1/128 scope host 

39

       valid_lft forever preferred_lft forever

40

9: vs-client1@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

41

    link/ether be:11:6f:f9:95:54 brd ff:ff:ff:ff:ff:ff link-netnsid 0

42

    inet 10.83.5.3/24 scope global vs-client1

43

       valid_lft forever preferred_lft forever

44

    inet6 fe80::bc11:6fff:fef9:9554/64 scope link 

45

       valid_lft forever preferred_lft forever

46

47

root@phenix:~# ip netns exec vnet-client2 ip addr show up

48

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

49

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

50

    inet 127.0.0.1/8 scope host lo

51

       valid_lft forever preferred_lft forever

52

    inet6 ::1/128 scope host 

53

       valid_lft forever preferred_lft forever

54

11: vs-client2@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

55

    link/ether 0a:60:ae:22:b7:df brd ff:ff:ff:ff:ff:ff link-netnsid 0

56

    inet 10.83.5.4/24 scope global vs-client2

57

       valid_lft forever preferred_lft forever

58

    inet6 fe80::860:aeff:fe22:b7df/64 scope link 

59

       valid_lft forever preferred_lft forever

So hast man quasi schonmal 3 netns, mit eigener IP, interface, und 
verbunden mit nem switch (der bridge).

All die namen der Interfaces und Namespaces kann man natürlich frei 
wählen. Sie dürfen aber nicht zu lange sein, das limit für 
interfacenamen ist recht klein...

Wenn du vom Host aus auf die Netns zugreifen willst, musst du der Bridge 
auch noch eine IP mit cidr geben.

Wenn die Sachem im Netns ins Internet können sollen, musst du die auch 
irgendwie daran anschliessen. z.B. das ethernet interface in die Bridge, 
oder auf dem Host ip forwarding zeugs und/oder NAT einrichten. In den 
Netzwerk Namespacen musst du natürlich dann noch die default route usw. 
setzen.

Am ende sollte man natürlich wieder aufräumen:

1

#!/bin/bash

2

ip link del br-fake-switch

3

ip link del vm-client1

4

ip link del vm-client2

5

ip link del vm-server

6

ip netns del vnet-server

7

ip netns del vnet-client1

8

ip netns del vnet-client2

Den Teil mit dem erstellen vom netns, und ein Programm darin ausführen, 
könnte man natürlich in ein script oder so zur wiederverwendung packen: 
(ungetestet)

1

#!/bin/bash

2

set -e

3

4

if [ $# -lt 3 ]

5

then

6

  echo "Usage: $0 name addr cmd..."

7

  exit 1

8

fi

9

10

name="$1"; shift

11

addr="$1"; shift

12

13

ip netns add "vnet-$name"

14

15

cleanup(){

16

  ip link del "vm-$name"

17

  ip netns del "vnet-$name"

18

}

19

trap cleanup EXIT INT TERM

20

21

ip link add "vm-$name" type veth peer "vs-name"

22

ip link set "vm-$name" master br-fake-switch

23

ip link set "vs-$name" netns "vnet-$name"

24

ip netns exec "vnet-$name" ip addr add "$addr" dev "vs-$name"

25

ip netns exec "vnet-$name" ip link set lo up

26

ip netns exec "vnet-$name" ip link set "vs-$name" up

27

28

ip netns exec "vnet-$name" "$@"

Daniel A. schrieb:
> Das ganze könnte man mit network namespeces, veth pairs, und einer
> bridge realisieren. Zumindest unter linux

Dein Enthusiasmus in allen Ehren. Aber ein simpler Network-Alias wie von 
Stefan im 
Beitrag "Re: TCP Port x-IP Server Client Modell" 
gezeigt, reicht dafür vollkommen aus. Mutmaßlich braucht man nichts 
dergleichen. Einen einfachen TCP-Server setzt man als Fingerübung mal 
eben auf. Dito den dazu passenden Client. Z.B. einen Server, der echo 
oder rot13 implementiert. Und dann läßt man sie auf dem selben Node (vm, 
whatever) aufeinander los.

Und ich gehe jede Wette ein, daß in C# ein entsprechendes Beispiel schon 
fertig ist. Der TE ist doch bloß ein Student, der faul ist, sich das 
anzulesen. Und die Vorlesung hat er geschwänzt.

Daniel A. schrieb:
> Das ganze könnte man mit network namespeces, veth pairs, und einer
> bridge realisieren. Zumindest unter linux. Beispiel: (Muss als root
> ausgeführt werden)
>
> [code]
> #!/bin/bash

Das ist ja nun mehrfach ins Knie geschossen. Um nicht zu sagen, einmal 
mit der Maschinenpistole auf Knie gehalten.

Erstens brauch man alles nicht, weil der:die Fragesteller:in sich mit 
großer Wahrscheinlichkeit verrannt hat und nicht verstanden hat dass bei 
TCP/IP die Beteiligten eindeutig über ein 5-Tupel assoziiert sind 
[Protokoll (z.B. TCP oder UDP), lokale IP-Adresse, lokaler Port, 
entfernte IP-Adresse, entfernter Port]

Wenn nur ein einziges dieser 5 Daten unterschiedlich ist haben wir eine 
andere Assoziation. Bei TCP würde man sagen eine andere Verbindung.

Wenn man dann noch wie üblich Clients so programmiert, dass sie 
ephemeral Ports verwenden, dann braucht man nicht mehr. Dann haben wir 
Clients die auf dem selben Rechner, mit der selben IP-Adresse (und sei 
es localhost 127.0.0.1), mit jeweils unterschiedliche Ports laufen, und 
damit unterschiedliche und eindeutige Client-Server Assoziationen.

Zweitens, wenn man schon kompliziertere Netzwerk-Konfigurationen macht, 
dann doch nicht händisch mit ip, ifupdown, nmcli oder was zur 
Hölle es da noch auf der Kommandozeile gibt. Schön deklarativ mit 
Netplan und der Tag ist dein Freund.

https://netplan.io/
https://netplan.io/examples/

Ach ja, und an den den Windows-Clown der sich beschwert dass es kein GUI 
gibt. Doch, gibt es natürlich. Natürlich auch mehrere. Aber dazu ein GUI 
nehmen ist wie sich zusätzlich noch in das andere Knie schießen. Man 
könnte auch sage nur für Leute, die beim Dummklicken in GUIs einen 
freudigen Erregungszustand erreichen.

Hannes J. schrieb:
> Erstens brauch man alles nicht, weil der:die Fragesteller:in sich mit
> großer Wahrscheinlichkeit verrannt hat und nicht verstanden hat dass bei
> TCP/IP die Beteiligten eindeutig über ein 5-Tupel assoziiert sind
> [Protokoll (z.B. TCP oder UDP), lokale IP-Adresse, lokaler Port,
> entfernte IP-Adresse, entfernter Port]

Davon würde ich nicht ausgehen. Es geht um unbekannt Client & Server 
Programm, wer weiss, was diese intern machen. Villeicht nutzen die 
Clients UDP Mulicast oder so, mit fixer Adresse. Oder vielleicht wird 
die IP von der Serveranwendung dummer weise statt einem Session Token 
oder so verwendet, statt richtiges Session Handling zu implementieren. 
Wer weiss, mit wass der TO sich da herum quälen muss.

c-hater schrieb:
> Um unter Windows mehrere IPs an eine NIC zu hängen, brauche ich nicht in
> die Untiefen der Editierung irgendwelcher Textdateien abzusteigen,
> gefolgt von einem (oder u.U. mehreren) kryptischen Kommandos

Heutzutage installieren die meisten Distros - zumindest wenn man eine 
Desktop Umgebung installiert - so weit ich weiss NetworkManager. Dort 
kann man auch mehrere IPs usw. für ein Interface bequem per GUI 
einstellen.

c-hater schrieb:
> Letztlich kommt man aber
> auch bei Windows11 immer noch zum guten altbekannten Explorer-Objekt für
> die NICs. Welches im Übrigen viel mehr Funktionalität bereitstellt als
> z.B. /etc/network/interfaces bei den debilen (ähem... debianischen oder
> wie sagt man das richtig?) Linuxen.

Einige sehen die Datei mittlerweile als veraltet an. Ich bin mir nicht 
sicher, ob es in debian überhaupt noch standardmässig verwendet wird.

Aber in der Datei da kann man beliebige Kommandos ausführen lassen, z.B. 
wenn das Interface hoch kommt usw. "up commando". Gibt unter anderem 
{pre-,,post-}{up,down}. Zusätzlich ist es erweiterbar, man kann da also 
beliebige Optionen usw. erfinden, wenn man will. Anders als bei einem 
GUI-Dialog, gibt es also nichts, was man da nicht einstellen könnte.

c-hater schrieb:
> Nur dann, wenn man was konfigurieren will, was Microsoft im GUI nicht
> vorgesehen hat (was allerdings eher selten vorkommt), dann wird es auch
> unter Windows richtig nervig.

Sowas, wie ich in meinem letzten Beitrag gepostet habe, kann man meines 
Wissens in Windows nicht machen (mal abgesehen von der WSL2, aber das 
ist ja eine Linux VM).
Das ist nämlich bei weitem nicht nur dem Host mehrere IPs geben. 
Stattdessen sehen Programme in unterschiedlichen Netzwerk Namespaces 
eine komplett eigene und unabhängige Netzwerkkonfiguration, mit 
separaten Interfaces, Routing, etc. Und bei dem Beispiel komplett ohne 
einen vollständigen Container oder eine VM aufsetzen zu müssen, da 
schalte ich nur gerade den Netzwerkteil für ein Programm um.

Der Grund, warum ich das gezeigt habe, statt einfach das Setzen mehrerer 
IPs beim Host ist, dass man beim Programm nicht einstellen können muss, 
welche es nimmt.

Bei Serveranwendungen ist es üblich, angeben zu können, auf welchem Port 
auf Verbindungen gewartet wird. Bei Clients wäre es vermutlich auch 
möglich, zu implementieren, dass eine bestimmte IP zum initiieren einer 
Verbindung verwendet wird.

Aber, in beiden fällen muss das Programm es auch zulassen, dass man das 
konfigurieren kann. Das sieht nämlich alle IPs. Und bei Client 
Programmen ist das eher unüblich, denen ist das in der regel egal, von 
wo aus das zum Ziel kommt. Dann hätte man zwar mehrere IPs, aber kann 
den Client nicht dazu bringen, eine Bestimmte zu nutzen, bzw. eine 
andere, als andere Instanzen.

Indem man das Programm aber einfach in einem Netzwerk Namespace startet, 
kann man das Problem umgehen. Das Programm sieht dann einfach die 
Netzwerk config von dem Netzwerk Namespace, nutzt die IPs, die da 
eingestellt sind, usw.

Stefan ⛄ F. schrieb:

> Wie konfiguriert man denn jetzt in Windows?

Ähnlich.

fchk