netzwerkprotokoll auf basis einer tcp verbindung erstellen

Sengha

Mitglied
ich möchte ein eigenes netzwerkprotokoll auf basis einer tcp verbindung erstellen. ist die klasse java.net.Socket dafür das richtige?
 
Zuletzt bearbeitet von einem Moderator:
Ja, wobei ich das Protokoll versuchen würde nicht von TCP abhängig zu machen sondern nur von InputStream und OutputStream, dann kann man später leichter den Unterbau verändern/austauschen.
 
Jaein, wenn du genu weißst das TCP das richtige ist, kannst du das ganze minimal effizienter schreiben, wenn du nciht weißst wie der unterbau ist musst du sonst nämlich eine methode zur zuverläassigen datenübertraung einbauen, um vom unterbau unabhängig zu sein. Selbiges bietet dir aber tcp schon, womit du doppelt sichern würdest.
 
Ja, wobei ich das Protokoll versuchen würde nicht von TCP abhängig zu machen sondern nur von InputStream und OutputStream, dann kann man später leichter den Unterbau verändern/austauschen.

und welche klasse könnte ich dann für eine verbindung nutzen, also auf basis des "Network-Layers" (IP-Protokoll) des OSI-Modells?
 
In java haste nur auf basis von UDP oder TCP möglich. (Ausser halt per native bibliotheken).
Aber wozu brauchst du ein eigenen Protokoll auf IP ebene?, klingt schwer noch konzeptfehler!

Am rande TCP/UDP halten sich nciht an das OSI modell, das osi modellist nur ein Konzept das nicht benutzt wird. TCP/UDP haben nur 4 ebenen, und die sind auch nicht so stark getrennt, weil die daten per pointer einfach durchgereicht werden, was streng nach dem model fehlerhaft ist, da müsste man alles von ebene zu ebene kopieren um eine trennung zu gewährleisten.
 
Zuletzt bearbeitet:
Am rande TCP/UDP halten sich nciht an das OSI modell, das osi modellist nur ein Konzept das nicht benutzt wird. TCP/UDP haben nur 4 ebenen, und die sind auch nicht so stark getrennt, weil die daten per pointer einfach durchgereicht werden, was streng nach dem model fehlerhaft ist, da müsste man alles von ebene zu ebene kopieren um eine trennung zu gewährleisten.
Quelle?

Ich halte das für ein Gerücht. Wieso sollte es nur 4 Schichten haben? Was ist mit z.B. DNS, welches auf TCP und UDP aufsetzt? Keine eigene Schicht? Und das Programm das die DNS-Abfrage sendet? ...

Und woher beziehst du die Information mit dem Pointer? Bei so vielen Stacks die es gibt sollte man sowas nicht pauschalisieren.
 
ich studiere den Mist? 2 te Semester Wirtschaftsinformatik, da hat man das dann schon gemacht.

TCP/IP versus OSI
ISO/OSI-7-Schichtenmodell
ect. sagt google.

Und das mittem Pointer is sehr simple, in jeder schicht werden zusätzliche header hinzugefügt, (wenn man mal vom end stück des ethernet layers absieht), er rest wird nur per pointer weitergereicht, weil es x mal schneller ist als jedes mal die daten zu kopieren.(natürlich tut das nciht ejde implementation , aber genug, die von windows zb)

DNS ist bereits ein Protokoll auf UDP basis, so wie zb bei CSS der Netzwerkcode. Die zusätzlichen layer sind über den netzwerkstack (sogar nach osi modell).
 
Zuletzt bearbeitet:
Am rande TCP/UDP halten sich nciht an das OSI modell, das osi modellist nur ein Konzept das nicht benutzt wird
Das stimmt nicht. Wie du selber sagst, ist das ein Modell und kein Konzept. Es hält sich also niemand an dieses Konzept, sondern man kann Implementierungen auf dieses Modell abbilden.

Und dieses Modell kann auch auf TCP/IP angewendet werden, wenn auch dann eine "Schicht" der Implementierung nach eine oder mehrere Schichten des OSI Modells realisiert.
 
Der Furz hats gut zusammengefasst worauf ich hinaus wollte.

Halte ich jetzt nicht für eine vertrauenswürdige Quelle, jeder kann irgendwelchen Käse ins Internet stellen, wie in diesem Fall.
Schon ehr glaubwürdig, aber schießt du dir bei dem Link nicht in den eigenen Fuß? Unten wird TCP als Schicht 4 aufgeführt ...
Und das mittem Pointer is sehr simple, in jeder schicht werden zusätzliche header hinzugefügt, (wenn man mal vom end stück des ethernet layers absieht), er rest wird nur per pointer weitergereicht, weil es x mal schneller ist als jedes mal die daten zu kopieren.(natürlich tut das nciht ejde implementation , aber genug, die von windows zb)
a) Die MTU liegt meist bei ~1500Byte, die zu kopieren ist ein Klacks!
b) Du sagt korrekt, dass die Schichten eigene Header hinzufügen. Aber eben _Header_!. Das nutzende Programm weiß nicht wieviel Header kommen und schreibt seine Daten an die erste freie Stelle des reservierten Speichers. Und genauso geht es durch die nächsten Schichten. Dein IP-Stack nimmt sicherlich auch nur _einen_ Pointer entgegen für die Nutzdaten, und der muss die Daten in der richtigen Reihenfolge enthalten. Sonst müsste ja das "dümmere" IP ja alle Eigenarten von TCP/UDP/... kennen und alle Header die es gibt die man über einen Pointer übergeben könnte. Ebenfalls wäre es schlechtes Design. Daher widerspreche ich weiterhin deiner Behauptung mit den Pointern und zweifle das auch bei Windows an. Ich hoffe ich habe am WE Zeit das mal zumindest im Linuxkernel zu prüfen.

ich studiere den Mist? 2 te Semester Wirtschaftsinformatik, da hat man das dann schon gemacht.
... Mit Betonung auf Wirtschaft! 😉
 
Zuletzt bearbeitet:
blub lbub habe nie was andere gesagt, ging mir doch nru um die frage bzgl welches layer des osi models die ip eben is, weil es so wirkte das als ob der fragende das ganze 1zu1 übertragen wollte, und wollte halt nur darauf hinweisen dass für die praxis so relativ 100% irrelevant ist, weil man nunmal keine echte alternativ derzeit hat zu dem tcp/Udp Ip model.

Fact ist halt Tcp/Ip gabs vor dem OSI model, und die höheren eben werden nicht kopiert sondern nur durchgereicht, weil es schlichtweg schneller ist von mr aus per pointer,referenzen keksen würßten is egal geht nur darum das tcp nicht sauber zwischen layern trennt, während nach OSI nur eine kopie weitergereicht werden dürfte.

Btw der tcp stack hat halt nur 4 schichten, darauf kann man zwar die 7 schichten von osi pressen aber das wars auch.
------
Wozu antworte ich überhaupt, tendenziell wird jetzt eh was zu meiner rechtschreibung gesagt als irgetwas was dem Threadstarter hilft.
 

Zurück
Oben