tami: beschäftigt(e) sich hier jemand mal mit sockets und tls/ssl?

Beitrag lesen

hi unknown,

Da bist du schon in die erste Stolperfalle gegrubelt. UDP ist ein verbindungsloses Transport-Protokoll, dass eben NICHT mit Sockets arbeitet.
Auch UDP ist mit der Soket API möglich.

Dann aber scheinbar auch ohne?

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".
Vielleicht solltest du mal sagen, wo du dich bewegst. Soket ist für mich immer C, denn als C-API wurde diese definiert.

Das ist ja auch o.k.. Irgendeine Struktur oder Konvention braucht es doch wohl, damit ich den Providern und Routern im Internet da draußen mitteilen kann, an wen mein Paket gehen soll, oder?

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?
Was heißt ohne Soket? Auf Treiberebene? Das willst du sicher nicht.

Nein, will ich nicht. Deshalb liege ich mit "ich will Socket" ja vermutlich auch richtig ;-). Und wenn Socket als C-Api definiert wurde, ist das wohl der Anfang für mich. Ich vermute mal, dass ich damit sowohl senden wie auch "listenen" bzw. empfangen kann.

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 ...;
Du sendest erst mal Bytewürst. Die kannst du interpretieren wie du willt. Über eine weitere Schicht.

Ja, so dachte ich bereits.

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".
Eine IP-Adresse wird schon vorhanden sein, vielleicht nicht durch den Provider gesetzt, ähnlich SLIP.

Ich finde dazu leider nix im Netz. Muss die Person nochmal fragen, wo sie das her hat.

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.
Sokets sind ja nicht in einer .NET Bibliothek programmiert, sondern als C-API. In .NET gibt es sicherlich einen Wrapper als Objekt.

.net interessiert mich jetzt nicht. Eher noch Java, wenn/weil das Android-tauglich wäre. .NET vielleicht, wenn das so auf Win-Phones klappen würde, wenn es überhaupt mal dazu käme.

mfg

tami