Hallo, ich steige gerade in Winsock und TCP ein und hätte da ein paar Fragen: Ist es üblich, über den gleichen Port zu Senden und zu Empfangen? Oder nimmt man eher zwei verschiedene Ports? Was ist der Vorteil bzw. Nachteil? Gruß Peter
Peter schrieb: > Ist es üblich, über den gleichen Port zu Senden und zu Empfangen? > Oder nimmt man eher zwei verschiedene Ports? > Was ist der Vorteil bzw. Nachteil? überlegt doch einfach mal bei es bei http läuft.
oder nimmt du auch 2 Telefon zum anrufen, eines zum hören und eines zum sprechen?
Peter II schrieb: > oder nimmt du auch 2 Telefon zum anrufen, eines zum hören und eines zum > sprechen? Wenn ich also morgen mit dem Orient-Express nach Berlin fahre und übermorgen wieder zurück, dann kann ich das vergessen, weil ich ja erst auf den gleichen Zug zum Heimfahren warten muss. Oder wie hast Du das gemeint? Ok, ich weiss schon was Du meinst, aber schlüssig ist das nicht.
Der Port ist die Durchwahl auf dem Server. Wenn auf zwei unterschiedlichen Servern je ein Prozess auf Port 42 hört (listen()), dann jeder dieser beiden, Multithreading oder select() vorausgesetzt, jeweils eine (Client-)Verbindung zu Port 42 auf dem anderen aufmachen. Ein Client hat keinen wählbaren Port, den er benutzt, nur einen, den er beim Server erreichen will.
Peter schrieb: > Wenn ich also morgen mit dem Orient-Express nach Berlin fahre und > übermorgen wieder zurück, dann kann ich das vergessen, weil ich ja erst > auf den gleichen Zug zum Heimfahren warten muss. Nein, so ist es nicht. Das Ziel deiner Fahrt, bzw. der Startpunkt deiner Rückreise ist jeweils Berlin. Es geht dabei nicht um den Weg. Der Server hat einen Port auf dem er empfängt und sendet. Der Client hat einen Port auf dem er sendet und empfängt. Das ist (meist) ein anderer Port.
DirkB schrieb: > Der Client hat einen Port auf dem er sendet und empfängt. Das ist > (meist) ein anderer Port. Der wird i.d.R. dynamisch vom IP-Stack zugewiesen und ist auf Ebene der Socketprogrammierung recht uninteressant. Es gibt Protokolle, die für jede Richtung der Kommunikation ein eigenes Socket-Pärchen aufmachen, ftp ist ein unrühmliches Beispiel davon. So etwas bereitet in Router/NAT-Umgebungen immer wieder Freude; wenn kein wirklich zwingender Zwang (eine Alliteration! Ha!) besteht, sollte man so etwas sein lassen. Die stinknormale Art der Kommunikation, wie sie bei http, smtp, pop3 & Co. oder auch simplem telnet erfolgt --Server lauscht auf festgelegtem Port, Client verbindet sich mit diesem und nutzt lokal einen dynamisch zugewiesenen-- ist für bidirektionale Kommunikation, also das Senden und Empfangen von Daten, bestens geeignet.
Hallo Peter, das kommt ganz drauf an, was Du machen möchtest. Es spricht überhaupt nichts dagegen, den gleichen Port zu nehmen. Das ist sogar die beste Möglichkeit, wenn Du z. B. mehrere Verbindungen parallel erlauben möchtest, vielleicht durch Firewalls mußt o. ä. Lesen und Schreiben auf dem gleichen Socket ist unabhängig und kann auch aus unterschiedlichen Threads erfolgen (sogar aus unterschiedlichen Prozessen, aber das erfordert größere Verrenkungen, daher nur der Vollständigkeit halber erwähnt). Es gibt verschiedene Modi, wie man das ansteuert (blockierendes oder nichtblockierenes I/O). Normalerweise hast Du bei einer Socket-Verbindung eine Server-Seite, die auf eine Verbindung wartet und eine Client-Seite, die die Verbindung aufbaut. Das kann man natürlich je nach Anwendung auch mischen, wie "Stolzer" geschrieben hat, das heißt aber, daß man beides auf beiden Seiten implementieren muß und löst noch nicht die Frage, auf welcher der beiden Verbindungen man dann liest und auf welcher man schreibt ;-) . Ein Negativbeispiel, welche Probleme man mit verschiedenen Ports bekommen kann, ist das ftp-Protokoll, das einen Socket für Kommandos und einen weiteren Socket für Daten benutzt, wobei (im Active Mode) der ftp-Server eine Verbindung zum Client aufbauen muß und meistens an Firewalls, NAT u. ä. scheitert, weshalb man den "Passive Mode" eingeführt und die Sache kompliziert hat. Um Dir etwas Genaueres raten zu können, müßte man wissen, was Du machen möchstest, also welche Parteien mit welchen anderen kommunizieren sollen und was für Nachrichten verschickt werden sollen. Tschüß, Matthias
Hallo und erst mal vielen Dank für die vielen, ausführlichen Antworten! Rufus Τ. Firefly schrieb: > Es gibt Protokolle, die für jede Richtung der Kommunikation ein eigenes > Socket-Pärchen aufmachen, ftp ist ein unrühmliches Beispiel davon. Es liegt kein Grund dafür vor - je einfacher desto besser würd ich sagen. Matthias H. schrieb: > Um Dir etwas Genaueres raten zu können, müßte man wissen, was Du machen > möchstest, also welche Parteien mit welchen anderen kommunizieren sollen > und was für Nachrichten verschickt werden sollen. Letztlich soll mit Mikrocontrollern eine Verbindung (am besten mit TCP?) mit dem PC hergestellt werden. Allerdings habe ich bisher noch keinen uC im Einsatz. Momentan sende ich von/zum localhost.
Peter schrieb: > (am besten mit TCP?) Dir ist aber klar, daß zumindest kleine (8 bitter) µCs in der Regel keine integrierte Hardware für Ethenet und keine Bibliotheken für TCP mitbringen. Einfach im Sinne von schnell implementiert ist Kommunikation über die serielle Schnittstelle. Auch die ist duplexfähig. Für TCP/IP würde ich dann schon zu etwas leistungsfähigeren 16 oder 32 Bit µCs schauen, aber du hast nicht gesagt welche µCs du meinst.
Udo Schmitt schrieb: > Dir ist aber klar, daß zumindest kleine (8 bitter) µCs in der Regel > keine integrierte Hardware für Ethenet und keine Bibliotheken für TCP > mitbringen. Das i.d.R. nicht, aber es gibt genügend Beispiele, wo jemand eine ISA-Netzwerkkarte (bzw. einen Netzwerkbaustein à la RTL8019 o.ä.) an einen AVR gebastelt hat und auf dem AVR einen Webserver laufen lässt.
Rufus Τ. Firefly schrieb: > aber es gibt genügend Beispiele, wo jemand eine > ISA-Netzwerkkarte (bzw. einen Netzwerkbaustein à la RTL8019 o.ä.) an > einen AVR gebastelt hat und auf dem AVR einen Webserver laufen lässt. Du hast völlig recht, es gibt oder gab ja sogar von Pollin das Board mit Ethernet. Was ich sagen wollte ist daß es für einen 8 bitter nicht unbedingt das 'natürliche' Protokoll ist. Schon allein weil der Protokollstack auch schon einen ordentlichen Teil von Prozessorleistung und Platz im Programmspeicher belegt.
Udo Schmitt schrieb: > Für TCP/IP würde ich dann schon zu etwas leistungsfähigeren 16 oder 32 > Bit µCs schauen, aber du hast nicht gesagt welche µCs du meinst. Ich werde es erstmal mit einem PIC32 Demo-Board versuchen. Der fertige Stack von Microchip und die Demos scheinen mir ein guter Einstieg. Was gibt es denn für alternativen zu TCP, wenn ich eine gesicherte Datenübertragung machen will? UDP? - Da muss ich dann eine Menge 'außenrum' programmieren, was ich so gelesen haben. Udo Schmitt schrieb: > Was ich sagen wollte ist daß es für einen 8 bitter nicht unbedingt das > 'natürliche' Protokoll ist. Und welches wäre das dann?
Peter schrieb: > Was gibt es denn für alternativen zu TCP, wenn ich eine gesicherte > Datenübertragung machen will? > UDP? - Da muss ich dann eine Menge 'außenrum' programmieren, was ich so > gelesen haben. Es gibt noch ein Protokoll namens SCTP, das gesichert, aber nachrichtenorientiert ist. Ich muß zugeben, daß ich damit keine praktische Erfahrung habe, dazu ist es zu exotisch ;-) . Oder man strickt sich was auf der Basis von nacktem IP selber, aber das will man aus mehreren Gründen nicht wirklich ;-) . > Udo Schmitt schrieb: >> Was ich sagen wollte ist daß es für einen 8 bitter nicht unbedingt das >> 'natürliche' Protokoll ist. > > Und welches wäre das dann? Ich denke, Udo meint, Seriell-ASCII oder so ;-) . Wenn Du einen so "großen" Mikrocontroller nimmst, wie Du nehmen möchtest, sollte sich das erledigt haben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.