[TCP/IP]Kan luisteren en versturen op dezelfde poort?

[Tukk]

Disclaimer: Ik dacht dat dit een makkelijke n00b-vraag was, maar na mijn vraag Tukk in "Het Grote "Kleine" Mededelingentopic dee..." bleek in het KMT geen antwoord te komen. Vandaar dat ik de vraag hier nu stel. hij blijkt moeilijker te beantwoorden dan ik dacht

Ik heb een discussie met een collega, over TCP/IP.

Kan een proces luisteren en sturen over dezelfde poort op een server?

ik heb meerdere bronnen doorgenomen, onder andere wikipedia, http://www.tcpipguide.com/free/index.htm en enkele boeken, maar geen bron kan mijn vraag ontkennen of bevestigen.

Ik zeg van wel, de pakketjes hebben een bron en een destination de poort is bekend, daarom is er mijns inziens technischh geen reden om het lusiteren en sturen op 1 poort niet mogelijk te maken. Daarentegen kan ik geen pakket/systeem bedenken dat dit ook daadwerkelijk doet. Wie weet het antwoord?

[Orion84]

Dat is toch gewoon hoe het standaard werkt? Jij maakt een TCP verbinding met poort 80 van een webserver, stuurt over die verbinding een HTTP GET en de server stuurt over diezelfde TCP verbinding, dus vanaf poort 80, de opgevraagde pagina terug, om maar een voorbeeld te nemen.

Welke poort jij aan jou kant gebruikt maakt in principe geen reet uit. In bovenstaand voorbeeld zal je browser een willekeurige vrije poort kiezen (in een bepaald bereik, aangezien voor sommige poorten min of meer vast ligt waar ze voor gebruikt mogen worden).

[ Voor 3% gewijzigd door Orion84 op 01-12-2009 14:28 ]

[Tukk]

Ja natuurlijk, anders definieer je automatisch een maximum van gebruikers op een webserver (namelijk 65536 - 1023)...

[JackBol]

Een sessie moet altijd uniek te definieren zijn met een vijf-tupel:

• IP Protocol Number (bijv. TCP/UDP/ICMP etc).
• Source IP
• Source Port
• Destination IP
• Destination Port

Pas als je van 2 datastreams de bovenstaande 5 velden het zelfde hebt raakt je TCP/IP stack pas in de war.

[ Voor 16% gewijzigd door JackBol op 01-12-2009 16:43 ]

[CyBeR]

Tukk schreef op dinsdag 01 december 2009 @ 14:41:
Ja natuurlijk, anders definieer je automatisch een maximum van gebruikers op een webserver (namelijk 65526 - 1023)...

Nou moet daar bijgezegd worden dat de gemiddelde webserver er een stuk eerder mee kapt dan dat...

[CodeCaster]

Vraag: kun je met een client [url]http://localhost/[/] bereiken wanneer er op diezelfde computer een webserver draait?
Antwoord: ja, zie _DH.

Tukk schreef op dinsdag 01 december 2009 @ 14:41:
Ja natuurlijk, anders definieer je automatisch een maximum van gebruikers op een webserver (namelijk 65536 - 1023)...

Uitgebreider antwoord: die limiet is er dus wel, want wanneer jij een verbinding maakt naar een webserver op poort 80, zal de webserver niet antwoorden via poort 80, maar via een Wikipedia: Ephemeral port. Hierdoor blijft de serverpoort 80 vrij voor nieuwe verbindingen. Hierdoor kan er ook aan throttling gedaan worden: de server zet eenvoudigweg de listener op poort 80 uit zolang $aantal_verbindingen >= $max_verbindingen, zodat oude verbindingen wel blijven bestaan.

Op de client gebeurt hetzelfde, de uitgaande poort 80 wordt eigenlijk niet gebruikt, er wordt een willekeurige (meestal oplopend om collisions te voorkomen) poort gekozen uit de tijdelijke range en ingesteld als "source port", terwijl je "destination port" op 80 wordt gezet.

[ Voor 24% gewijzigd door CodeCaster op 01-12-2009 16:56 ]

[TrailBlazer]

De rule of thumb is dat inkomende sessies op een poort onder 1024 binnenkomen en uitgaande sessies worden opgezet van een poort vanaf 1024. Er zijn echter zat protocollen (mysql bijvoorbeeld) die luisters op een poort >1024.
Om terug te komen op de vraag. de 5 voudige tuple van protocol source/dest port en source/dest ip moet uniek zijn.

[CyBeR]

CodeCaster schreef op dinsdag 01 december 2009 @ 16:52:

Uitgebreider antwoord: die limiet is er dus wel, want wanneer jij een verbinding maakt naar een webserver op poort 80, zal de webserver niet antwoorden via poort 80, maar via een Wikipedia: Ephemeral port. Hierdoor blijft de serverpoort 80 vrij voor nieuwe verbindingen.

Euh, nee hoor. Die ephemeral port is aan de clientkant. De server doet alles lekker op poort 80. Sniff maar 's.

Op de client gebeurt hetzelfde, de uitgaande poort 80 wordt eigenlijk niet gebruikt, er wordt een willekeurige (meestal oplopend om collisions te voorkomen) poort gekozen uit de tijdelijke range en ingesteld als "source port", terwijl je "destination port" op 80 wordt gezet.

Hier komt de ephemeral port juist tevoorschijn. Een client zegt 'ik wil een socket, welk nummer kan me niet schelen, en ik ga die connecten naar 1.2.3.4:80'. Het OS pakt dan een random port (binnen de geconfigureerde range) en laat de app z'n ding doen.

[CodeCaster]

CyBeR schreef op dinsdag 01 december 2009 @ 16:59:
Euh, nee hoor. Die ephemeral port is aan de clientkant. De server doet alles lekker op poort 80. Sniff maar 's.

quote: http://en.wikipedia.org/wiki/Ephemeral_port

or by a server application to free up a service's well-known listening port and establish a service connection to the client host

Ik zal vanavond thuis eens kijken, maar de laatste keer dat ik met sockets heb geprogrammeerd moest er één listening socket zijn op de gewenste poort, die dan een verbinding binnenkreeg met bijbehorende handle. Deze handle moest je doorgeven aan een "accepting" socket, anders raakte je inkomende poort bezet.

[ Voor 3% gewijzigd door CodeCaster op 01-12-2009 17:09 ]

[CyBeR]

CodeCaster schreef op dinsdag 01 december 2009 @ 17:04:
[...]


[...]

Ik zal vanavond thuis eens kijken, maar de laatste keer dat ik met sockets heb geprogrammeerd moest er één listening socket zijn op de gewenste poort, die dan een verbinding binnenkreeg met bijbehorende handle. Deze handle moest je doorgeven aan een "accepting" socket, anders raakte je inkomende poort bezet.

Dat laatste is in het geval van, bijvoorbeeld, FTP. Daar wordt een extra verbinding naar de client geopend. De verbinding met poort 21 blijft in dat geval ook open, maar dat hoeft niet persee. Is afhankelijk van je protocol.

Je moet inderdaad wel je inkomende connection requests accept() en dan krijg je een nieuwe socket maar dat verandert niets aan de situatie met je poorten.

[CodeCaster]

CyBeR schreef op dinsdag 01 december 2009 @ 17:07:
Je moet inderdaad wel je inkomende connection requests accept() en dan krijg je een nieuwe socket maar dat verandert niets aan de situatie met je poorten.

Hoe weet de server dan welke socket bij welke client hoort? Volgens mij wordt dat toch echt gedaan aan de hand van de source-poort die de verbinding aan de serverkant heeft. Maar ik lees net:

quote: http://en.wikipedia.org/w...d_the_client-server_model

A server may create several concurrently established TCP sockets with the same local port number and local IP address, each mapped to its own server-child process, serving its own client process. They are treated as different sockets by the operating system, since the remote socket address (the client IP address and/or port number) are different, i.e. since they have different socket pair tuples.

Dus wanneer, bijvoorbeeld vanachter een NAT, twee clients tegelijk dezelfde source-poort gebruiken heb je een probleem? Of zou een router dat detecteren en vertalen?

[ Voor 4% gewijzigd door CodeCaster op 01-12-2009 17:18 ]

[CyBeR]

CodeCaster schreef op dinsdag 01 december 2009 @ 17:16:
[...]

Hoe weet de server dan welke socket bij welke client hoort? Volgens mij wordt dat toch echt gedaan aan de hand van de source-poort die de verbinding aan de serverkant heeft. Maar ik lees net:

We hadden toch al bedacht (zie _DH) dat elke TCP sessie vier unieke stukjes data heeft*? Zodra een ervan anders is, is 't een andere sessie, en dus een andere socket en een andere file descriptor. Verder kun je van elke socket opvragen welke adressen en poorten erbij horen.

*) Of vijf als je proto meetelt, maar binnen TCP staat dat redelijk vast.

Dus wanneer, bijvoorbeeld vanachter een NAT, twee clients tegelijk dezelfde source-poort gebruiken heb je een probleem? Of zou een router dat detecteren en vertalen?

Dat is inderdaad een probleem. En zodoende is elke NAT-router eigenlijk ook geen NAT-router maar een NAPT-router. Meestal wordt de source poort gelijk gehouden maar inderdaad als de source port conflicteert met een bestaande sessie dan moet er iets gedaan worden. Twee opties: de oude sessie wegknikkeren of de nieuwe omnummeren. Dat eerste is erg onaardig dus dan maar dat tweede.

[ Voor 5% gewijzigd door CyBeR op 01-12-2009 17:24 ]