Client Identifizierung bei selber IP [Indy 10]

[psycore]

Hallo,

da ich im Zuge dieses Threads mein Protokoll für eine Client/Server Anwendung neu konzipieren muss, wollte ich 2 Fliegen mit einer Klappe schlagen und mich gleich einem Problem stellen welches ich zuvor eher in der Schublade "Später behandeln" abgelegt hatte.

Und zwar geht es darum, dass ich zwei oder mehrere Clients, welche dieselbe IP haben (da sie hinter einem Routernetzwerk oder vom selben PC ausgeführt werden) nicht unterscheiden kann. Ich habe Lösungsansätze gefunden bei denen beim Connecten eine Eigenschaft an TIdIOHandler.Data gehängt wird. Das Problem ist allerdings dass Indy 10 diese Data Eigenschaft scheinbar nicht mehr besitzt.

Außerdem -> Verständnisfrage:

Bisher war es so, dass wenn ich 2 Clients von derselben IP am Server hatte, aber nur über einen TIdContext gesendet habe, doch beide das Paket erhalten haben. Passiert das dann mit eindeutig unterscheidbaren Clients nicht auch? Immerhin wird das Paket an die exakt selbe IP am selben Port geschickt...


Ich brauch nen kleinen Denkanstoß und bin für jeden Tipp dankbar,


mfg,


psycore

[Sherlock]

Theoretisch haben die Clients unterschiedliche Ports von denen aus sie senden. Der Port wird nämlich zufällig ausgewählt. Ist aber ein schwaches Kriterium. Du kannst es dennoch heranziehen wenn Du noch weitere Kriterien nimmst, wie zum Beispiel einen Rechnernamen oder Anmeldenamen oder so.

Sherlock

[psycore]

Naja, die Lösung überzeugt mich nicht sonderlich, zumal damit das Problem nicht gelöst ist wenn mehrere Clients vom selben PC starten

[Sherlock]

Gerade in dem Fall ist es gelöst, da für jeden Client ein anderer Port aufgemacht wird

Sherlock

[SirThornberry]

Also zu den zeiten als ich mich noch damit beschäftigt habe wurde beim Connect und allen anderen Methoden jeweils ein Object übergeben welches eindeutig war. Anhand dieses Objektes konnte man die Clients auch unterscheiden. Ich glbau es war ein TIdPeerThread oder so etwas.

[SirTwist]

Zitat von Sherlock:

Theoretisch haben die Clients unterschiedliche Ports von denen aus sie senden. Der Port wird nämlich zufällig ausgewählt. Ist aber ein schwaches Kriterium.

Das ist ziemlich falsch. Es ist das einzig ausreichende Kriterium. Ich gehe mal davon aus, dass es sich um TCP-Verbindungen handeln, dann werden diese genau über die Kombination (SrcIP, SrcPort, DstIP, DstPort) eindeutig bestimmt. Damit wäre aus Sicht des Server die Kombination (SrcIP,SrcPot) während einer bestehenden(!) TCP-Verbindung ein eindeutiges Identifizierungsmerkmal.

Der dazwischenhängende Router hat sonst keine Möglichkeit, die Verbindungen voneinander zu unterscheiden und die ankommenden Pakete zu den richtigen Rechnern im internen Netzwerk weiterzuleiten.

UDP ist da etwas kniffeliger, aber da UDP keine Verbindungen kennt, kommt es da auch darauf an, wie denn der Router konfiguriert ist, ob er Antwortpakete wieder zum ursprünglichen Absender durchlässt und für wie lange. Innerhalb dieses Timeouts am Router kann der Server genauso (SrcIP,SrcPort) als Identifizierung benutzen, nach Ablauf dieses Timeouts aber nicht mehr.

Gruß,
Sir Twist