![[HaBo]](/styles/default/logoklein.png){kind=small}
Socketprogrammierung
- Themenstarter lightf
- Beginndatum
hallo
deine Fragen kann ich zwar nicht direkt beantworten.
aber wenn du dich dafür interessierst kann ich dir das Tutoriel empfehlen:
Winsock Tutorial: Grundlagen und TCP
vieleicht hilft es dir ja^^
deine Fragen kann ich zwar nicht direkt beantworten.
aber wenn du dich dafür interessierst kann ich dir das Tutoriel empfehlen:
Winsock Tutorial: Grundlagen und TCP
vieleicht hilft es dir ja^^
Hackse
0
Prinzipiell gibt es für alle Standardaufgaben Bibliotheken. Ich rate Dir von ihnen ab. Warum? Weil Du nichts dabei lernst wenn Du eine fertige Funktion aufrufst. Wenn es Dir darum geht etwas bis ins Detail zu verstehen, solltest Du das Rad neu erfinden.
Für Sortieralgorithmen wie Heapsort, Quicksort, Selectionsort, Mergesort, Bubblesort, gibt es viele fertige Funktionen, die man einfach aufrufen kann. Dennoch wirst Du durch den Aufruf keine einzige davon verstehen, geschweige denn deren asymptotische Laufzeitkomplexität berechnen können. Es geht den Universitäten bei der Vermittlung solcher Inhalte natürlich nicht darum, dass Du irgend eine fertige Funktion aufrufen kannst, sondern Du selbst sollst eine solche Funktion entwickeln können. Du sollst also nicht bloß Anwender, sondern Denker/Entwickler sein, denn das ist es was den Hacker vom Skriptkiddy unterscheidet.
Niemand bewirbt sich als "Netzwerkprogrammierer in C". Firmen sind eher an Lösungen interessiert. Am Markt bist Du gut, wenn Du viele Technologien, Paradigmen und Sprachen drauf hast. Ansi-C ist da nur ein geringer Teil.
Zum Verständnis einer TCP-basierten Socketverbindung ist Ansi-C sehr geeignet, da Du hier eben nicht einfach eine fertige Funktion aufrufst, sondern jeden Teilschritt der Kommunikation verstehen und programmieren musst und nur so lernt man es.
Du fragtest noch nach Security. Nun, um einen DDOS-Angriff zu programmieren, sind das die Grundlagen.
Für Sortieralgorithmen wie Heapsort, Quicksort, Selectionsort, Mergesort, Bubblesort, gibt es viele fertige Funktionen, die man einfach aufrufen kann. Dennoch wirst Du durch den Aufruf keine einzige davon verstehen, geschweige denn deren asymptotische Laufzeitkomplexität berechnen können. Es geht den Universitäten bei der Vermittlung solcher Inhalte natürlich nicht darum, dass Du irgend eine fertige Funktion aufrufen kannst, sondern Du selbst sollst eine solche Funktion entwickeln können. Du sollst also nicht bloß Anwender, sondern Denker/Entwickler sein, denn das ist es was den Hacker vom Skriptkiddy unterscheidet.
Niemand bewirbt sich als "Netzwerkprogrammierer in C". Firmen sind eher an Lösungen interessiert. Am Markt bist Du gut, wenn Du viele Technologien, Paradigmen und Sprachen drauf hast. Ansi-C ist da nur ein geringer Teil.
Zum Verständnis einer TCP-basierten Socketverbindung ist Ansi-C sehr geeignet, da Du hier eben nicht einfach eine fertige Funktion aufrufst, sondern jeden Teilschritt der Kommunikation verstehen und programmieren musst und nur so lernt man es.
Du fragtest noch nach Security. Nun, um einen DDOS-Angriff zu programmieren, sind das die Grundlagen.
Hackse
0
Deine Annahme ist nicht korrekt.
Es gibt weltweit sehr viel mehr Codezeilen in C als in Ruby, Perl oder Python, vermutlich sogar mehr Codezeilen in C als in den o.g. drei Skriptsprachen zusammen. Unix, Linux, Windows, ... Kernel und komplette Betriebssysteme sind in C geschrieben. Die meisten Anwendungen werden in C / C++ geschrieben (Winzip, Amarok, Ktorrent, ...) allein schon wegen der Performance. Seit ein paar Jahren macht sich auch Java ganz gut.
Versuche mal einen Web-Server wie den Apache in einer rein skriptbasierten Sprache zu schreiben. Das geht performancetechnisch gar nicht.
Du darfst auch eine Skriptsprache nicht mit einer Programmiersprache vergleichen, denn diese erfüllen einen anderen Zweck. Bitte nicht missverstehen, ich liebe Skriptsprachen und habe mehrere hundert Skripte in Form kleiner bis mittelgroßer Problemlösungen auf den unterschiedlichsten Systemen geschrieben. Für größere und komplexere Anwendungen muss jedoch eine Programmiersprache her, aus guten Grund.
Exploits kann man auch mit Skriptsprachen schreiben, das ist korrekt. IT-Security besteht jedoch nicht nur aus Exploits, sondern aus sehr viel mehr. Letzten Endes ist es irrelevant in welche Programmier- oder Skriptsprache man einen Exploit schreibt. Funktionieren muss er, nur darauf kommt es an. Ich für meinen Teil schreibe u.a. Crypto-Anwendungen und Decrypter. Da kommt es extrem auf die Performance an, die Du mit keiner Scriptsprache der Welt hinbekommst. Audit-Tools wie "John" sind daher selbstverständlich auch in C geschrieben.
Meine Empfehlung lautet das eigene Wissen nicht auf eine bestimmte Skript-Sprache zu beschränken, sondern sich mit vielen Dingen zu befassen, die gängig sind. Hierzu gehören Perl, Python, PHP ebenso wie C, C++ und Java.
... Keep an open mind ...
Es gibt weltweit sehr viel mehr Codezeilen in C als in Ruby, Perl oder Python, vermutlich sogar mehr Codezeilen in C als in den o.g. drei Skriptsprachen zusammen. Unix, Linux, Windows, ... Kernel und komplette Betriebssysteme sind in C geschrieben. Die meisten Anwendungen werden in C / C++ geschrieben (Winzip, Amarok, Ktorrent, ...) allein schon wegen der Performance. Seit ein paar Jahren macht sich auch Java ganz gut.
Versuche mal einen Web-Server wie den Apache in einer rein skriptbasierten Sprache zu schreiben. Das geht performancetechnisch gar nicht.
Du darfst auch eine Skriptsprache nicht mit einer Programmiersprache vergleichen, denn diese erfüllen einen anderen Zweck. Bitte nicht missverstehen, ich liebe Skriptsprachen und habe mehrere hundert Skripte in Form kleiner bis mittelgroßer Problemlösungen auf den unterschiedlichsten Systemen geschrieben. Für größere und komplexere Anwendungen muss jedoch eine Programmiersprache her, aus guten Grund.
Exploits kann man auch mit Skriptsprachen schreiben, das ist korrekt. IT-Security besteht jedoch nicht nur aus Exploits, sondern aus sehr viel mehr. Letzten Endes ist es irrelevant in welche Programmier- oder Skriptsprache man einen Exploit schreibt. Funktionieren muss er, nur darauf kommt es an. Ich für meinen Teil schreibe u.a. Crypto-Anwendungen und Decrypter. Da kommt es extrem auf die Performance an, die Du mit keiner Scriptsprache der Welt hinbekommst. Audit-Tools wie "John" sind daher selbstverständlich auch in C geschrieben.
Meine Empfehlung lautet das eigene Wissen nicht auf eine bestimmte Skript-Sprache zu beschränken, sondern sich mit vielen Dingen zu befassen, die gängig sind. Hierzu gehören Perl, Python, PHP ebenso wie C, C++ und Java.
... Keep an open mind ...
1. Warum sollte ich mir einen Vergleich verbieten lassen?
2. Was ist der gute Grund?
blue182
0
Oh man... Performance ist das Zauberwort. Sorry, aber was ist da so schwer dran zu verstehen?
BTT. Socketprogrammierung gehört zum Standartrepertuar eines jeden Programmierers. Es gibt zig Kommunikationsprotokolle, aber alle Kommunizieren über einen Weg: Sockets.
Schau dir mal die Dokumentation vom Zotteljedi an btw.
/€1:
Nichts deato trotz, es gibt genügend Große Projekte die in Skriptsprachen umgesetzt sind. Heutige Rechner haben die Leistung. Schließlich lasse ich einfach mal so im Raum stehen, dass Java - die aktuell populärste Sprache - interpretiert wird.
Zuletzt bearbeitet:
Ich versteh immer noch nicht, warum ein Vergleich verboten sein sollte. Vielleicht fällt er ja zuungunsten der Skriptsprache aus, aber dann sind sie ja vergleichbar.
Und "Skriptsprachen" von "Programmiersprachen" abzugrenzen, ist genauso Schwachsinn. Das sind keine disjunkten Mengen, sondern Unter- und Obermenge. Auch in einer Skriptsprache wird programmiert.
Jein. Der gängige weg ist, Java zu Bytecode zu compilen und diesen dann von der VM interpretieren zu lassen. Die größeren VMs besitzen allerdings einen JIT, der stellenweise doch nativen Code erzeugt. Gerade bei langlebigen Prozessen führt das dazu, dass nach einer gewissen Zeit die kritischen Teile des Programm nativ ausgeführt werden.
Hackse
0
Wenn Du mengentheoretische Beschreibungsaspekte zum Vergleichen von Programmier- und Skriptsprachen verwendest, solltest Du auch einen gültigen Definitionsbereich angeben. Zwei Teilmengen einer gemeinsamen Obermenge können durchaus disjunkt sein. Um verifizieren (oder falsifizieren) zu können, ob dies auf Deine These zutrifft, bedarf es hier der Information in welcher Art Du Programmier- und Skriptsprachen vergleichst. Beziehst Du Dich auf die Syntax, die Semantik oder worauf genau?
Verbieten möchte ich nichts. Du kannst auch Äpfel mit Birnen vergleichen, wenn Du Spaß daran hast. Vielmehr wollte ich mit meiner Nachricht ausdrücken, dass es Teile der Informatik gibt, die man mit Programmiersprachen effizienter abbilden kann und Teile, die man mit Skriptssprachen effizienter abbilden kann. Sicherlich gibt es auch Dinge, die man mit beiden abbilden kann.
Ich habe das Ganze hier beschrieben, vielleicht wird's dann deutlicher.
Natürlich, aber wie kommt man auf die Idee, diese beide Teilmengen "Programmiersprachen" und "Skriptsprachen" zu nennen? Man kann sich natürlich vieles zusammendefinieren, aber so rein intuitiv klingt "Programmiersprache" nach einem allgemeineren Begriff. Und erzähl mal den php/python/ruby-Usern, dass sie keine Programmierer sind
Ja, eben. Das ist wohl die einzige wirklich allgemeingültige Aussage, die man hier treffen kann.
Ansonsten: Brauchen wir nen Mod, der hier wieder aufs Thema zurücklenkt? Ich versuchs mal.
>1. Wie gefragt sind denn Netzwerkprogrammierer in C und C++ heutzutage?
"Kaum", da "Netzwerkprogrammierer" und "C/C++" schon sehr einschränken. Es gibt sicher Leute, die nichts anderes machen, aber sich von vornherein nur auf Netzwerk und C/C++ darauf zu beschränken, klingt nicht sinnvoll (falls es überhaupt geht).
>2. Welche Rolle spielt Socketprogrammierung in C, C++ in der Security-Branche? Oder werden eher andere Programmiersprachen und Bibliotheken genutzt?
Das sind einfach zwei verschiedene Aspekte. Du kannst auch in vielen anderen Sprachen ein (raw) Socket aufmachen und deine Pakete selbst zusammenbauen, vermutlich sogar bequemer als in C/C++. Die Thematik ist sicher nicht unwichtig.
Die Sprachwahl sollte davon abhängen, ob das Ergebnis den Aufwand rechtfertigt. Ich möchte aber anmerken, dass jede größere Software aus unterschiedlichen Komponenten besteht, von denen nicht alle die gleichen Anforderungen an die Sprache stellen: Die Sprachwahl richtet sich also nicht zwingend nach den Gesamtpaket, sondern nach der Komponente - im Grunde genau das, was Hackse in seinem verlinkten Post schreibt.
Ansonsten zitier ich mal Hackse:
Man braucht zwar Spezialisten, aber keine Fachidioten.
Hackse
0
Die Bezeichnung "Skriptsprache" ist der korrekte, gängige Begriff und keineswegs ausgedacht.
Sieh Dir mal folgende beiden Links an:
Universität Paderborn
Wikipedia
Zuletzt bearbeitet:
Sorry, vielleicht hab ich mich falsch ausgedrückt, der Begriff "Skriptsprache" ist natürlich etabliert. Aber der erste Satz des Wikipedia-Artikels bringt es doch auf den Punkt: "Skriptsprachen (häufig auch Scriptsprachen) sind Programmiersprachen".
Hackse
0
Natürlich sind Skriptsprachen auch Programmiersprachen. Auch wollte ich nicht ausdrücken, dass Leute, die ausschließlich Skriptsprachen verwenden, keine Programmierer sind.
Der Grund meiner initialer Unterscheidung zwischen Programmiersprachen und Skriptsprachen unterlag meiner These, dass es Dinge gibt, die man nicht ausschließlich in Skriptsprachen schreiben kann, einfach weil die Performance es nicht zulässt oder weil es eben bestimmte Dinge gibt, die sich nur in Binärcode abbilden lassen (z.B. Kernelmodule).
Du kannst keinen performanten Web-Server in einer Skriptsprache abbilden. Ich meine hiermit nicht die Web-Applikation in PHP, sondern die Serversoftware, die die Anfragen von etlichen Usern annimmt und verarbeitet.
Du kannst keinen performanten Bruteforcer (z.B. für MD5) in einer rein skriptbasierten Sprache abbilden
Du kannst keine performante CAD-Applikation rein skriptbasiert schreiben
Skriptsprachen sind, so sehr ich sie schätze und täglich verwende, für manche Aufgaben zu langsam und aufgrund des zu interpretierenden Codes ungeeignet.
EDIT:
Solltest Du der Ansicht sein, dass meine These hinsichtlich Performance und Skriptsprachen nicht korrekt ist, können wir einen Performance-Vergleich durchführen. Hierzu wird es eine rechenintensive Aufgabenstellung geben, die ich z.B. in Ansi-C löse und Du in einer beliebigen Skriptsprache. Dann können wir fundiert bewerten, ob die These korrekt ist oder nicht.
Zuletzt bearbeitet:
Sing# für Singularity ist Managed Code, d.h. Bytecode, wird per VM interpretiert. Und der Kernel ist im Wesentlichen in Sing# geschrieben
Pyrit, aktuell effizientester WPA/WPA2-Cracker... geschrieben in Python. Okay, cheatet, nutzt OpenCL
Bitte kein Geflame über "real man" Programmiersprachen. Ihr könnt dazu gerne einen eigenen Thread aufmachen
OT:
=> Programmieraufgaben Unterforum wartet auf Dich
Wobei man bedenken sollte, dass es in den "realen" Anwendungen oft genug nicht nur um reine Berechnungen geht (sondern auch Verarbeitung/Speicherung und "Zurverfügungstellung" von Input/Daten) und viele "Scriptsprachenbibliotheken" in C implementiert sind, so dass primitve Operationen auf diesen Datentypen (Hashmaps, Listen, Stringsuche usw) nur gewrapte Aufrufe der C-Bibliothek sind.
Reine Numbercruncher sind daher sowas wie "Microbenchmarks". Es wäre also schön, wenn es nicht nur einseitige "berechne Pi/Primzahl &Co" Aufgaben wären, sondern auch vielleicht "parse Datei X und gebe dazu irgendwelche Statistiken aus"
Ich würde im übrigen behaupten, dass ANSI-C auch bei weitem nicht so schnell ist. Wer real exisitierende MD5/SHA1 Bruteforcer anschaut:
Distracted: SHAbr update, I passed 60 Mhashes/s
sieht, dass der Code dank Macros quasi "Meta-Assembly" entspricht, bei dem der Compiler nur noch die jeweiligen XMM Register "frei" vergeben darf. Hierzu reicht es also bei weitem nicht aus, reines C/C++ "perfekt" zu beherrschen - man muss auch die jeweilige Hardwareplattform kennen (wieviele Register stehen zur Verfügung, wie lässt man den Compiler das am besten Parallelisieren usw.)
Allgemeines imho:
Man sollte immer zwischen "prinzipiell/theoretisch" und "praktisch/wie es tatsächlich ausschaut" unterscheiden. Um tatsächlich performante Programme zu schreiben, braucht man ein solides, abstraktes Hintergrundwissen über Algorithmen und Datenstrukturen sowie über die jeweilige Plattform (was bietet OS an Features, was bietet die Hardware und wie sage ich dem Compiler, dass er diese nutzen soll?).
In der Praxis sind Teile der "0815" C Anwendungen nicht selten langsamer als "0815" Pythonanumsetzung, einfach weil der C "Programmierer" meint, das Rad neu erfinden zu müssen und/oder unpassende Umsetzungen wählt (weil z.B die Datenstrukturen nicht in der Standardbibliothek vorhanden sind) und der Scriptsprachler einfach auf bestehende Bibliotheken zurückgreift ("Batteries included" - sei es HTTP Reader, XML-Parser oder Dictionaries/Sets, die auf einer soliden, getesteten usw. C Bibliothek basieren).
Speicherverwaltung ist ein Thema für sich - nur weil man den Speicher selber manuell alloziert und freigibt, wird das Programm dadurch nicht effizienter oder schneller (wie z.B ein while-Loop, der mittels recv Daten empfägt und dabei jedesmal den Buffer mittels realloc um 1 Byte erweitert
)
OT:
Aber bitteEDIT:
Solltest Du der Ansicht sein, dass meine These hinsichtlich Performance und Skriptsprachen nicht korrekt ist, können wir einen Performance-Vergleich durchführen. Hierzu wird es eine rechenintensive Aufgabenstellung geben, die ich z.B. in Ansi-C löse und Du in einer beliebigen Skriptsprache. Dann können wir fundiert bewerten, ob die These korrekt ist oder nicht.
=> Programmieraufgaben Unterforum wartet auf Dich Wobei man bedenken sollte, dass es in den "realen" Anwendungen oft genug nicht nur um reine Berechnungen geht (sondern auch Verarbeitung/Speicherung und "Zurverfügungstellung" von Input/Daten) und viele "Scriptsprachenbibliotheken" in C implementiert sind, so dass primitve Operationen auf diesen Datentypen (Hashmaps, Listen, Stringsuche usw) nur gewrapte Aufrufe der C-Bibliothek sind.
Reine Numbercruncher sind daher sowas wie "Microbenchmarks". Es wäre also schön, wenn es nicht nur einseitige "berechne Pi/Primzahl &Co" Aufgaben wären, sondern auch vielleicht "parse Datei X und gebe dazu irgendwelche Statistiken aus"
Ich würde im übrigen behaupten, dass ANSI-C auch bei weitem nicht so schnell ist. Wer real exisitierende MD5/SHA1 Bruteforcer anschaut:
Distracted: SHAbr update, I passed 60 Mhashes/s
sieht, dass der Code dank Macros quasi "Meta-Assembly" entspricht, bei dem der Compiler nur noch die jeweiligen XMM Register "frei" vergeben darf
. Hierzu reicht es also bei weitem nicht aus, reines C/C++ "perfekt" zu beherrschen - man muss auch die jeweilige Hardwareplattform kennen (wieviele Register stehen zur Verfügung, wie lässt man den Compiler das am besten Parallelisieren usw.)Allgemeines imho:
Man sollte immer zwischen "prinzipiell/theoretisch" und "praktisch/wie es tatsächlich ausschaut" unterscheiden
. Um tatsächlich performante Programme zu schreiben, braucht man ein solides, abstraktes Hintergrundwissen über Algorithmen und Datenstrukturen sowie über die jeweilige Plattform (was bietet OS an Features, was bietet die Hardware und wie sage ich dem Compiler, dass er diese nutzen soll?).In der Praxis sind Teile der "0815" C Anwendungen nicht selten langsamer als "0815" Pythonanumsetzung, einfach weil der C "Programmierer" meint, das Rad neu erfinden zu müssen und/oder unpassende Umsetzungen wählt (weil z.B die Datenstrukturen nicht in der Standardbibliothek vorhanden sind) und der Scriptsprachler einfach auf bestehende Bibliotheken zurückgreift ("Batteries included" - sei es HTTP Reader, XML-Parser oder Dictionaries/Sets, die auf einer soliden, getesteten usw. C Bibliothek basieren).
Speicherverwaltung ist ein Thema für sich - nur weil man den Speicher selber manuell alloziert und freigibt, wird das Programm dadurch nicht effizienter oder schneller (wie z.B ein while-Loop, der mittels recv Daten empfägt und dabei jedesmal den Buffer mittels realloc um 1 Byte erweitert
)
Zuletzt bearbeitet:
Hackse
0
Code:
Sing# für Singularity ist Managed Code, d.h. Bytecode, wird per VM interpretiert. Und der Kernel ist im Wesentlichen in Sing# geschriebenPyrit verwendet nicht nur Binärcode zur Beschleunigung, sondern macht (z.B. via CUDA) auch Gebrauch von GPU um einen massiv-parallelen Algorithmus zu simulieren. Kannst ja mal versuchen so was in einem Shellskript mit der selben Performance abzubilden.
Hackse
0
Gerade in C hapert es an Funktionalitäten, z.B. verglichen mit Java oder Perl's CPAN. Da bleibt einem manchmal nix anderes übrig das Rad neu zu erfinden.
Der Performance-Vergleich zweier Sprachen sollte sich grundsätzlich auf identische Algorithmen beziehen. Wenig Sinn macht das Ganze z.B. wenn man in zwei Sprachen Algorithmen abbildet, die verschiedenen Komplexitätsklassen genügen und dann die Performance vergleicht. Es lassen sich also entweder identische Algorithmen in verschiedenen Sprachen vergleichen oder verschiedene Algorithmen in der selben Sprache (einfach um zwei Algos zu vergleichen, z.B. Heapsort vs. Quicksort). Eine Mischform aus beidem macht IMHO wenig Sinn.
Genug OT von mir für heute.