nicht angemeldet
hi 1UnitedPower,
und Danke für die Antwort.
Was macht denn eine Socket-Verbindung für dich aus?
Ja, gute Frage. Erstmal den grundsätzlichen Verbindungsaufbau zwischen zwei über IP-Adressen und einen entsprechend offenen Port definierte Endgeräte (PC, Smartphone, ggfs. "Server"). Um sich dann per TCP oder UDP Pakete zu senden.
Da bist du schon in die erste Stolperfalle gegrubelt. UDP ist ein verbindungsloses Transport-Protokoll, dass eben NICHT mit Sockets arbeitet.
"Internet-Sockets
Internet-Sockets ermöglichen die Kommunikation mittels bestimmter Kommunikationsprotokolle. Generell kann man unterscheiden zwischen Stream Sockets und Datagram Sockets: Stream Sockets kommunizieren über einen Zeichen-Datenstrom; Datagram Sockets über einzelne Nachrichten. In der Netzwerkkommunikation verwenden Stream Sockets meist TCP, Datagram Sockets üblicherweise UDP. "
ist das, was Wikipedia dazu von sich gibt (http://de.wikipedia.org/wiki/Socket_(Software))
Ich bin verständnismäßig mal auf der Suche nach der einfachsten Möglichkeit, "hello world" von einem Gerät aufs andere zu schicken. "Nimm folgenden String (oder ein paar bytes die du aus einer Datei liest) und schicke sie an IP-Adresse son.ste.wa.s vielleicht noch an Port 3333 oder so". Wie geht, das mit minimalem Aufwand (bei son.ste.wa.s:3000 müsste ja dann auch ein listener vorhanden sein) und wäre das dann schon ein socket oder geht das auch ohne socket?
Wenn ich an Sockets denke, denke ich an rohe Protokolle wie TCP. Die Arbeit damit möchte ich eigentlich vermeiden, weil sie a) ein sehr tiefes Verständnis erfordert und b) schon tausendfach erledigt wurde und c) die üblichen Anforderungen bereits in darauf aufbauenden Protokollen implementiert sind.
Danke, irgendwie muss ich mal rauskriegen, was es mit diesem "sehr tiefen Verständnis" auf sich hat.
Ein Socket-Interface zu nutzen, ist keine große Kunst, die Kunst ist es zu entscheiden, ob sich der Einsatz einer so rohen Technik lohnt und sich erstmal umzuzesehen, ob es nicht was passenderes gibt.
Ziel wäre erstmal der o.g. minimale Messenger aber erweitert dann auch allgemein Dateiinhalte (egal welches Format) und vielleicht auch darauf aufbauend Sprache in Echtzeit. Ich dachte jetzt in meinem jugendlichen Leichtsinn, dass sich der Versand der Bitfolge "hello world" im Prinzip doch decken müsste mit jeder längeren Bitfolge, außer dass dann eben mehr Pakete entstehen. Ob das dann ein .pdf, .jpg oder .wav ist, wäre ja für das Übertragungsprinzip wohl egal, dachte ich ...;
Was aber ist mit Smartphones (Messenger-App). Ich habe gehört, dass die (wenn sie nicht im WLAN sind) in Deutschland aus rechtlichen Gründen nicht über eine IP-Adresse verfügen (Angreifbarkeit), finde dazu aber so ohne weiteres nichts bei Google dazu.
Ich weiß nicht, was du da gelesen hast. Die IP-Adresse ist im OSI-Schichten-Modell sehr weit unten angeordnet, wenn man darauf verzichtet muss man wirklich eine ganze Menge Räder neuerfinden und ob die Alternative, dann sicherer ist, bleibt auch noch offen. Aber ich kenne mich in der nativen Smartphone-Entwicklung auch wirklich nicht aus.
Es ging darum, in einem Gespräch, dass angeblich IP-Adressen für Smartphones nicht vergeben werden, weil das zu unsicher wäre (in den USA sei das anders). Dabei macht das natürlich wohl einen Unterschied, ob die in einem WLAN (mit IP) angemeldet sind oder eben per "mobile Daten".
Gut, dann müsste man sich mit wohl mit der Aussage: "Verschlüsselungsverfahren nach gängigem Standard, die nach heutigem Kenntnisstand nicht knackbar sind" begnügen.
Dann bist du mit SSL sehr gut bedient. SSL fügt sich fast nahtlos in bestehende Konzepte der Datenübertragung ein, das macht es aus meiner Perspektive so angenehm und es gilt gemein hin als sicher.
Jo, das hatte ich auch schon gedacht. Dem entnehme ich dass WebRTC nicht mit SSL-Verschlüsselung funktioniert. Sieht zumindest nach extrem-kurz-googlen so aus ...;
Das ging jetzt in die Richtung, wie unkown sie beantwortet hat: http://forum.de.selfhtml.org/my/?t=216838&m=1488103. Neben Windows und BSD wäre dann noch meine Frage, wie es mit Android und MacOS steht und was es sonst noch für "relevante" Betriebssysteme gäbe.
Nein, ich wollte eigentlich in eine ganz andere Richtung lenken, als unknown es getan hat. Mit node.js kannst du zum Beispiel auch rohe Sockets programmieren, aber node.js abstrahiert alle Betriebssystem-Abhängigkeiten für dich weg. Ein Node-Programm läuft auf allen Platformen, auf den Node.js läuft. Mit Java verhält es sich ähnlich. Wenn du dich von keiner Betriebssystem-Bibliothek, etwa .NET, abhängig machst, ist der Integrations-Vorgang in andere Systeme kein Beinbruch.
Das hört sich gut an, node.js. Java wäre sonst wohl die gängige Alternative insbesondere für Smartphoneentwicklung (Android).
Das WebRTC macht seine Aufgabe gut und sicher, die Sicherheit nützt aber nur, wenn andere Software-Komponenten auch mitspielen.
Ich dachte, wenn der Inhalt erstmal mit einem public-Key (oder in der Sitzung ausgehandeltem Key) verschlüsselt ist, ist der verschlüsselte Inhalt an sich erstmal (ziemlich) sicher. Die Angreifbarkeit wäre dann nur noch auf den jeweilige Endgeräten gebeben, wo die privat-Keys lagern oder das entschlüsselte Ergebnis dann im Klartext ...??? Oder was mit mit "anderen Softwarekomponenten" gemeint?
mfg
tami