nicht angemeldet
TCP/IP Kommunikation
Hallo zusammen,
ich habe eine Schnittstelle gebaut, die über TCP/IP mit anderen Anwendungen kommuniziert, Client-Server Modell. Die ausgetauschten Nachrichten sind entsprechend standardisiert.
Nun habe ich von dem EDV-Menschen auf der "anderen" Seite gehört, dass er gerne bei der TCP/IP Kommunikation zunächst die Länge der übermittelten Nachricht auf TCP/IP Ebene als 4-Byte-bitcodiertes Längenfeld haben möchte.
Ist das so üblich oder eher ein sehr individueller Wusch? Die Schnittstelle soll auch in anden IT-Umgebungen eingesetzt werden, daher frage ich.... Gibt es sonst noch wichtige Dinge, die bei der TCP/IP Kommunikation zu beachten sind?
Gruß
LeKuchen
-
Ist das so üblich oder eher ein sehr individueller Wusch?
Das ist absolut individuell.
Die Schnittstelle soll auch in anden IT-Umgebungen eingesetzt werden, daher frage ich....
Warum nimmst du dann nicht eines der vielen standardisierten Protokolle, die es schon gibt, sondern denkst dir ein eigenes aus?
-
Hallo,
Warum nimmst du dann nicht eines der vielen standardisierten Protokolle, die es schon gibt, sondern denkst dir ein eigenes aus?
Ich nehme ja ein standardisiertes Protokoll - nur leider stellt dieses frei, welches Kommunikationsprotokoll man nutzt und macht auch keinerlei Vorschriften zu der Kommunikation, nur die Nachrichten sind standardisiert. Und das Problem ist dann: Jede Anwendung machts dann natürlich anders...:(
Wobei TCP/IP sich als Quasi-Standard für die Kommunikation durchgesetzt aht.
Auszug aus dem Final Standard:
"Since the OSI protocols are not universally implemented we are interested in providing standards that will be useful in the interim. The universe of environments of interest includes,
but is not restricted to:
a) ad hoc environments that do not provide even basic transport reliability. Such environments consist of point-to-point RS-232 links, modems, and even LANs, if their connection to host computers is made via RS-232 communications links.
b) environments that support a robust transport level, but do not meet the high level requirements. This includes environments such as TCP/IP, DECNET, and SNA.
c) ISO and proprietary networks that implement up to presentation and other high level services. IBM’s SNA LU6.2 and SUN Microsystems’s NFS are examples of complete proprietary networks.
d) two or more applications running on the same physical and/or logical machine that are not tightly integrated. In these environments, the messaging capabilities may be provided by inter-process communications services (e.g., Pipes in a UNIX System)."LeKuchen
-
Warum nimmst du dann nicht eines der vielen standardisierten Protokolle, die es schon gibt, sondern denkst dir ein eigenes aus?
Ich nehme ja ein standardisiertes Protokoll
Welches?
Ich spreche jetzt nicht von TCP. Sondern von etwas, was TCP benutzt, so wie HTTP, FTP o.ä.
nur leider stellt dieses frei, welches Kommunikationsprotokoll man nutzt und macht auch keinerlei Vorschriften zu der Kommunikation, nur die Nachrichten sind standardisiert. Und das Problem ist dann: Jede Anwendung machts dann natürlich anders...:(
Wenn es einen Standard gibt, dann kann man den ja irgendwo nachlesen. Und grundsätzlich ist es für die Implementierung immer gut, sich an folgende Regel zu halten: Sei streng mit dem, was du sendest, und tolerant bei dem, was du empfängst.
Wenn dein Standard kein 4-Byte-Längenfeld vorsieht, kannst du keines einbauen. Da muß die Gegenseite eben mitzählen, wieviele Bytes sie kriegt, und ein Endekennzeichen abwarten.
Wobei TCP/IP sich als Quasi-Standard für die Kommunikation durchgesetzt aht.
TCP und IP sind aber Protokolle, die lediglich die Kommunikation zwischen zwei Stationen regeln - aber nicht, was und wie kommuniziert wird. Das ist Sache eines darüberliegenden Protokolls.
Auszug aus dem Final Standard:
Wenn du irgendeinen TCP-Standard zitierst, dann zielst du falsch.
-
-