nicht angemeldet
beschäftigt(e) sich hier jemand mal mit sockets und tls/ssl?
hi,
würde gerne mal wissen, ob sich jemand mit sockets und tls/ssl auskennt bzw.
finde z.b.:
http://openbook.galileocomputing.de/linux_unix_programmierung/Kap11-014.htm
und natürlich wikipedia:
http://en.wikipedia.org/wiki/Berkeley_sockets
[http://de.wikipedia.org/wiki/Transport_Layer_Security]
ziel wäre eine beispielanwendung für eine erstmal minimale (text) datenübermittlung am besten peer-2-peer (vermutlich über eine socketverbindung) und darauf aufbauend dann eine nach wissenschaftlichen erkenntnissen unknackbare verschlüsselung.
so wie ich es verstehe, greift die socketverbindung dabei auf funktionen des betriebssystems zu? macht also einen unterschied, ob eine andwendung zb. auf win läuft, linux, unix, macos oder android etc.pp.???
und wo entstehen sicherheitslücken, rein theoretisch?
mfg
tami
-
hi,
[http://de.wikipedia.org/wiki/Transport_Layer_Security]
http://de.wikipedia.org/wiki/Transport_Layer_Security
ja, der vorschaubutton hat viel schönes ...;
mfg
tami
-
Meine Herren!
ziel wäre eine beispielanwendung für eine erstmal minimale (text) datenübermittlung am besten peer-2-peer (vermutlich über eine socketverbindung)
Was macht denn eine Socket-Verbindung für dich aus?
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.Insbesondere wenn Sicherheit eine wichtige Rolle spielt, rate ich davon ab, das Rad neu zu erfinden. Der einzige legitime Grund für eine solche Grundlagen-Forschung ist imho. ein autodidaktischer.
Wenn ich eine P2P-Anwendung entwickeln müsste und die nicht-funktionalen Anforderungen es erlauben, würde ich tatsächlich zu WebRTC greifen, weil es mir viel Arbeit erspart: Es kommt von Haus aus mit Verschlüsselung (DTLS ~= SSL). Falls der Verbindungsaufbau erfolglos bleibt stehen automatisierte Ausweich-Möglichkeiten zur Verfügung und solche kleine Gimmiks, die man als Einzelperson unmöglich alle erfassen kann.
und darauf aufbauend dann eine nach wissenschaftlichen erkenntnissen unknackbare verschlüsselung.
Das gibt es leider nicht. Es fängt schon damit an, dass die meisten etablierten Verschlüsselungs-Verfahren eng mit den ungelösten Geheimnissen der Primzahlen verworren sind. Falls morgen jemand einen Polynomialzeit-Algorithmus für einen Primzahlentest entwickelt, sind alle mir bekannten Verschlüsselungs-Algorithmen hinfällig. Unter gewissen Hypthesen (P ≠ NP) gibt es aber tatsächlich sichere™ Verschlüsselungsverfahren.
so wie ich es verstehe, greift die socketverbindung dabei auf funktionen des betriebssystems zu? macht also einen unterschied, ob eine andwendung zb. auf win läuft, linux, unix, macos oder android etc.pp.???
Fast jede Software greift auf Funktionen des Betriebssystems zurück. Ich verstehe diese Frage deshalb nicht ganz.
und wo entstehen sicherheitslücken, rein theoretisch?
Das ist nicht pauschal zu beantworten. Sicherheit zieht sich durch alle Schichten einer Software, vom Anwender bis hin zum digitalen Verbindungsaufbau zwischen zwei Rechnern.
--
“All right, then, I'll go to hell.” – Huck Finn-
hi 1UnitedPower,
ziel wäre eine beispielanwendung für eine erstmal minimale (text) datenübermittlung am besten peer-2-peer (vermutlich über eine socketverbindung)
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.
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. Da habe ich offenbar keinen blassen Schimmer. Dass es nicht lohnt, eigene Protokolle zu entwickeln, wenn es da schon genug taugliches gibt, scheint ja klar.
Insbesondere wenn Sicherheit eine wichtige Rolle spielt, rate ich davon ab, das Rad neu zu erfinden. Der einzige legitime Grund für eine solche Grundlagen-Forschung ist imho. ein autodidaktischer.
Ja, in dem Fall ist es beides, das Verständnis (s.o.) aber für eine reale Anwendung "das Rad neu erfinden" halte ich auch für falsch.
Wenn ich eine P2P-Anwendung entwickeln müsste und die nicht-funktionalen Anforderungen es erlauben, würde ich tatsächlich zu WebRTC greifen, weil es mir viel Arbeit erspart: Es kommt von Haus aus mit Verschlüsselung (DTLS ~= SSL). Falls der Verbindungsaufbau erfolglos bleibt stehen automatisierte Ausweich-Möglichkeiten zur Verfügung und solche kleine Gimmiks, die man als Einzelperson unmöglich alle erfassen kann.
Danke. http://de.wikipedia.org/wiki/WebRTC.
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.
Das gibt es leider nicht. Es fängt schon damit an, dass die meisten etablierten Verschlüsselungs-Verfahren eng mit den ungelösten Geheimnissen der Primzahlen verworren sind. Falls morgen jemand einen Polynomialzeit-Algorithmus für einen Primzahlentest entwickelt, sind alle mir bekannten Verschlüsselungs-Algorithmen hinfällig. Unter gewissen Hypthesen (P ≠ NP) gibt es aber tatsächlich sichere™ Verschlüsselungsverfahren.
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.
»
so wie ich es verstehe, greift die socketverbindung dabei auf funktionen des betriebssystems zu? macht also einen unterschied, ob eine andwendung zb. auf win läuft, linux, unix, macos oder android etc.pp.???
Fast jede Software greift auf Funktionen des Betriebssystems zurück. Ich verstehe diese Frage deshalb nicht ganz.
Das ging jetzt in die Richtung, wie unkown sie beantwortet hat: https://forum.selfhtml.org/?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.
und wo entstehen sicherheitslücken, rein theoretisch?
Das ist nicht pauschal zu beantworten. Sicherheit zieht sich durch alle Schichten einer Software, vom Anwender bis hin zum digitalen Verbindungsaufbau zwischen zwei Rechnern.
Ja, da lande ich dann wohl wieder bei dem "tiefen Verständnis" (s.o.). Wobei das WebRTC-Protokoll, wenn es denn zB. auch für eine Messenger-artige Anwendung für Smartphones tauglich wäre, ja offenbar einen großen Teil der kontrollierbaren Sicherheit abdecken sollte, oder?
mfg
tami
-
Meine Herren!
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.
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.
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.
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.
so wie ich es verstehe, greift die socketverbindung dabei auf funktionen des betriebssystems zu? macht also einen unterschied, ob eine andwendung zb. auf win läuft, linux, unix, macos oder android etc.pp.???
Fast jede Software greift auf Funktionen des Betriebssystems zurück. Ich verstehe diese Frage deshalb nicht ganz.
Das ging jetzt in die Richtung, wie unkown sie beantwortet hat: https://forum.selfhtml.org/?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.
und wo entstehen sicherheitslücken, rein theoretisch?
Das ist nicht pauschal zu beantworten. Sicherheit zieht sich durch alle Schichten einer Software, vom Anwender bis hin zum digitalen Verbindungsaufbau zwischen zwei Rechnern.
Ja, da lande ich dann wohl wieder bei dem "tiefen Verständnis" (s.o.). Wobei das WebRTC-Protokoll, wenn es denn zB. auch für eine Messenger-artige Anwendung für Smartphones tauglich wäre, ja offenbar einen großen Teil der kontrollierbaren Sicherheit abdecken sollte, oder?
Das WebRTC macht seine Aufgabe gut und sicher, die Sicherheit nützt aber nur, wenn andere Software-Komponenten auch mitspielen.
--
“All right, then, I'll go to hell.” – Huck Finn-
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
-
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.
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.
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.
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.
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.
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.
-
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
-
hi,
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.
s.a. http://www.willemer.de/informatik/unix/unprsock.htm
oder auch (für Windows)
<www.wut.de/pdf/e-58www-12-prde-000.pdf >
mfg
tami
-
s.a. http://www.willemer.de/informatik/unix/unprsock.htm
oder auch (für Windows)
<www.wut.de/pdf/e-58www-12-prde-000.pdf >
Hatte ich doch auch schon verlinkt.
-
hi,
s.a. http://www.willemer.de/informatik/unix/unprsock.htm
oder auch (für Windows)
<www.wut.de/pdf/e-58www-12-prde-000.pdf >
Hatte ich doch auch schon verlinkt.Sorry, ja, er war von Dir!
mfg
tami
-
-
-
Dann aber scheinbar auch ohne?
Was willst du wissen? Alles was auf Sockets aufsetzt und eine eigene Schnittstelle anbietet, kann diese gestalten wie sie lustig ist. Meist wird sie aber ähnlich aussehen.
-
hi,
Dann aber scheinbar auch ohne?
Was willst du wissen? Alles was auf Sockets aufsetzt und eine eigene Schnittstelle anbietet, kann diese gestalten wie sie lustig ist. Meist wird sie aber ähnlich aussehen.Fazit: ohne Socket "geht" es nicht ;-).
mfg
tami
-
-
-
hi,
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.Oder NAPT http://de.wikipedia.org/wiki/Network_Address_Port_Translation
https://www.lawblog.de/index.php/archives/2010/04/19/anonym-uber-umts/:
"Die angefragten IP-Adressen werden für den Internetzugang über das GPRS/UMTS-Mobilfunknetz verwendet. Hierbei wird Network-Address-Port-Translation (NAPT) eingesetzt, um nicht zu viele IP-Adressen zu verbrauchen (gemäß RIPE-Richtlinien). Da die IP-Adressen von vielen tausend Kunden gleichzeitig genutzt werden, ist eine genauere Zuordnung nicht möglich. "
mfg
tami
-
-
Meine Herren!
"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))
Da bin ich dann also in die Falle gegangen, nicht du, danke für die Korrektur.
Mit SSL meinte ich ich TLS, ja. Auch wenn es technisch nicht völlig exakt ist, werden die Begriffe häufig austauschbar verwendet.
--
“All right, then, I'll go to hell.” – Huck Finn
-
-
hi,
Dann bist du mit SSL sehr gut bedient.
= TLS? http://de.wikipedia.org/wiki/Transport_Layer_Security
mfg
tami
-
-
-
-
so wie ich es verstehe, greift die socketverbindung dabei auf funktionen des betriebssystems zu? macht also einen unterschied, ob eine andwendung zb. auf win läuft, linux, unix, macos oder android etc.pp.???
Ja, es macht einen Unterschied. Winsock unterscheidet sich in einigen Funktionen von BSD Sokets.
Mit Cygwin kannst du aber deine Linux Programme auch auf Windows Übersetzen.
Das sollte sich aber ohne große Mühe von einem ins andere portieren lassen.