TCP senden/empfangen an einem 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

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.

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.