Forum: PC-Programmierung C-Commandline Programm für Windows entwickeln


von Andi (Gast)


Lesenswert?

Hallo,

ich habe ein kleines Commandline-Programm in python geschrieben das 
folgendes macht:
- Dateien schreiben/lesen/manipulieren
- Daten über TCP-sockets schicken und empfangen (als Client).

Leider ist es ein wenig (ok, viel) zu langsam, ich werde es also in C 
neu schreiben.
Unter Linux kein Problem, brauchen würde ich es allerdings unter 
Windows.
Das letze mal dass ich in C für Windows programmiert habe ist gute 15 
Jahre her.;)

Könnt ihr mir einen einfachen Weg für meine Zwecke weisen?
Cross-Entwicklung (mingw, cygwin)?
Oder gleich unter Windows entwickeln (einfache IDE)?

Bin für jeden Tipp dankbar, andi

von Nop (Gast)


Lesenswert?

Andi schrieb:

> Könnt ihr mir einen einfachen Weg für meine Zwecke weisen?
> Cross-Entwicklung (mingw, cygwin)?

Cygwin hat den Vorteil, daß es wesentlich ähnlicher zu Linux wäre, 
solange Dir das in 32 bit ausreicht (außer die haben inzwischen auch 64 
bit). Du brauchst dann aber die Cygwin-DLL dazu, was zum Hausgebrauch 
und auch für GPL-Programme kein Problem ist, sonst aber U.u. schon.

MingW hingegen erzeugt Dir Windows-Programme in "richtig nativ", aber um 
den Preis, daß Du dann auch Windows-spezifisch programmieren mußt. Das 
ist bei Dateien kein Problem, weil man das ja sowieso mit den 
Standardfunktionen von C macht, aber bei den Sockets wird es 
ungemütlicher.

von Andi (Gast)


Lesenswert?

Nop schrieb:
> Cygwin hat den Vorteil, daß es wesentlich ähnlicher zu Linux wäre,
> solange Dir das in 32 bit ausreicht (außer die haben inzwischen auch 64
> bit). Du brauchst dann aber die Cygwin-DLL dazu, was zum Hausgebrauch
> und auch für GPL-Programme kein Problem ist, sonst aber U.u. schon.

32bit reichen sicher aus.
DLL ist kein Problem und Lizenzprobleme sehe ich auch keine.


> MingW hingegen erzeugt Dir Windows-Programme in "richtig nativ", aber um
> den Preis, daß Du dann auch Windows-spezifisch programmieren mußt. Das
> ist bei Dateien kein Problem, weil man das ja sowieso mit den
> Standardfunktionen von C macht, aber bei den Sockets wird es
> ungemütlicher.

Riecht das etwa nach winsocket?
Das habe ich noch in schlechter Erinnerung ... und würde lieber einen 
grossen Bogen um das Thema machen ;)

Also werde ich mir mal cygwin anschauen...

Danke, andi

von Sven L. (sven_rvbg)


Lesenswert?


von asdfasd (Gast)


Lesenswert?

Ich verstehe nicht, warum immer wieder Cygwin empfohlen wird - das Teil 
ist nen einziger Hack. Mag ja ok sein, um irgendwelche Posix-Programme 
zu bootstrappen, aber nichts für den Normalgebrauch - darin geschriebene 
Programme sind wie ein Fremdkörper im System.

Mingw dagegen kann ich empfehlen. Erstellt kleine Programme, und im 
Gegensatz zu Microsofts Compilern, ohne zusätzliche 
Runtime-Abhängigkeiten. Für Konsolenanwendungen genau das richtige. Mit 
etwas Sorgfalt läuft ein und dasselbe Programm dann auf allen 
Windows-Versionen ab 2000.

Für aufwendigere GUI-Anwendungen dürfte allerdings Visual-C & Co am 
einfachsten sein.

von asdfasd (Gast)


Lesenswert?

> Riecht das etwa nach winsocket?
> Das habe ich noch in schlechter Erinnerung ... und würde lieber einen
> grossen Bogen um das Thema machen ;)

Ne einfache TCP-Verbindung aufmachen und Daten austauschen geht mit 
winsock doch genau so wie unter Linux - die Funktionen heißen nur etwas 
anders.

Wenn du dir aber mal anschaust, was Cygwin für Klimmzüge macht, um 
select(2) zu implementieren ...


PS: im vorigen Post muss es "ab Windows NT" heißen ;-)

von Christian R. (supachris)


Lesenswert?

Konsolenprogramme kannst du auch mit Visual Studio in der kostenlosen 
Version entwickeln und bequem debuggen. Solange es kein mfc Programm ist 
(was man bei Konsole so gut wie nie braucht) sind da auch keine 
Abhängigkeiten zu vc runtimes. MFC geht eh nur in der Bezahlversion.
Der MS C++ Compiler ist hoch optimierend, obwohl das bei dir 
wahrscheinlich nicht relevant ist.

von Skyper (Gast)


Lesenswert?

Ich werfe mal C++ mi Qt ins Rennen...

Vorteil:
+ Sourcecode für Win, Linux "Mac" nutzbar (kompilierbar)
+ Bietet Netzwerkklassen (TCP/UDP Basis und auch einige Server-Klassen)
+ Wenn eine GUI benötigt wird, ist alles dabei...
+ Kompilieren unter Windows mit Visual Sudio (Community Studio reicht) 
oder auch mingw möglich
+ Qt-Creator als Entwicklungsumgebung für Linux, Windows (nutzt dann 
Debugger von VS) und Mac

Nachteil:
- Das Framework ist schon ziemlich "fett"
- Nicht wirklich "Keep it simple"

von Felix U. (ubfx)


Lesenswert?

asdfasd schrieb:
> Ne einfache TCP-Verbindung aufmachen und Daten austauschen geht mit
> winsock doch genau so wie unter Linux - die Funktionen heißen nur etwas
> anders.

Windows implementiert berkeley sockets. Für die socket-API sind sie 
sogar ausnahmsweise vom Großbuchstaben am Anfang der Funktion abgerückt. 
Die Funktionen heißen also nicht etwas anders sondern genau gleich - der 
einzige Unterschied ist, dass man vorher WSAStartup callen muss.

von Mampf unterwegs (Gast)


Lesenswert?

läuft der python code auch mit pypy zu langsam?

von asdfasd (Gast)


Lesenswert?

Naja, ähnlich ;-) Man muss schon einiges ändern: aus dem Kopf (ist schon 
ne Weile her): WSAStartup/WSACleanup am Anfang/Ende, nen Socket ist kein 
int, statt read/write/close recv/send/closesocket, anderes 
Errorhandling.

von Felix U. (ubfx)


Lesenswert?

asdfasd schrieb:

> nen Socket ist kein
> int,
Doch, mit Pointerbreite.
1
typedef UINT_PTR        SOCKET;

> statt read/write/close recv/send/closesocket

Bei read/write stimmt es schlicht nicht, die sind POSIX und gibt es 
dementsprechend auch. recv/send sind auch Teil der Berkeley API und 
sollten auch unter Unix verwendet werden, dafür sind sie ja da.
closesocket statt close ist tatsächlich der einzige Unterschied.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Christian R. schrieb:
> Solange es kein mfc Programm ist (was man bei Konsole so gut wie nie
> braucht) sind da auch keine Abhängigkeiten zu vc runtimes. MFC geht eh
> nur in der Bezahlversion.

Abhängigkeiten von irgendwelchen Runtimes sind auch bei 
MFC-Programmierung nicht nötig; man kann den Kram auch statisch linken. 
Und MFC-Unterstützung ist auch in der kostenlosen "Community Edition" 
enthalten, die der kastrierten "Express"-Version in mehreren Punkten 
deutlich überlegen ist.

Andererseits würde ich niemandem, der heute anfängt, Windows-Programme 
zu schreiben, dazu raten, das mit der MFC zu machen. Da gibt es schönere 
Alternativen.

Andererseits wollte der Threadstarter in C programmieren, da ist die MFC 
(wie jede ander C++-Klassenbibliothek) eh' nicht relevant.

Socket-Programmierung ist auch mit der nativen Win32-API möglich, es 
gibt keinen Grund, nur deswegen den Linux-Emulator "Cygwin" zu 
verwenden.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Andi schrieb:
> Leider ist es ein wenig (ok, viel) zu langsam
Sorry fuer den Einwand, aber:
Vielleicht solltest du mal schauen wo es da genau klemmt, anstatt 
dasselbe Problem ein zweitesmal zu loesen. In Python faellt es viel 
schneller auf, wenn ein Algorithmus schlecht implementiert ist, als in 
C/C++. Kannst du mal etwas Code zeigen? Dann kann man dir viel besser 
helfen.
Darueberhinaus geht die meiste Zeit des Pythoninterpreters dafuer drauf, 
festzustellen, welchen Typ die Variablen denn so haben. Du koenntest dir 
auch mal Cython anschauen: Python mit statischen Typinformationen. Dann 
kannst du wenigstens deinen Pythoncode nutzen und musst den nur etwas 
umbauen, anstatt alles in einer anderen Sprache neu schreiben zu 
muessen.
Cython: http://cython.org/

Andi schrieb:
> Cross-Entwicklung (mingw, cygwin)?
> Oder gleich unter Windows entwickeln (einfache IDE)?
Wenn du es unbedingt mit C/C++ machen willst:
C/C++ mit Qt und dem QtCreator. Der Qt-Installer bringt dir Mingw mit. 
Wenn du magst kannst du dir auch Clang als Compiler installieren. 
Toolchain tauschen ist in QtCreator kein Problem.

von Michael B. (laberkopp)


Lesenswert?

Andi schrieb:
> Könnt ihr mir einen einfachen Weg für meine Zwecke weisen?
> Cross-Entwicklung (mingw, cygwin)?
> Oder gleich unter Windows entwickeln (einfache IDE)?

Commandline, was willst du mit cygwin.

Hole dir das kostenlose Visual Studio Community Express von Microsoft 
und sage Datei Neu Projekt C++ Win32 Commandline und schreibe deinen 
Code, falls dir C++ zu kompliziert ist kannst du auch C als 
Dateinamenerweiterung eintragen. Python ist auch drin, willst du aber 
nicht noch mal.

Nicht jede Library, die du unter Phython genutzt hast, ist gleich dabei, 
aber eventuell war ja auch die Nutzung der mächtigen vorgefertigten 
Funktionen das Problem warum es langsam wurde.

Kaj G. schrieb:
> Wenn du es unbedingt mit C/C++ machen willst:
> C/C++ mit Qt und dem QtCreator.

Völliger Quatsch, er will ein Commandline-Programm, keine 
Windows-Oberfläche.

: Bearbeitet durch User
von nicht"Gast" (Gast)


Lesenswert?

Andi schrieb:
> Leider ist es ein wenig (ok, viel) zu langsam, ich werde es also in C
> neu schreiben.


Bist du dir sicher, dass du das nicht einfach nur falsch machst?

Gerade bei Python kann man als alter C Programmierer viel in der 
Performance versauen. Viele Dinge werden in Python anders gelöst und 
sind im C-Style deutlich langsamer.

von Joachim B. (jar)


Lesenswert?

hat noch keiner lcc gesagt?

http://www.cs.virginia.edu/~lcc-win32/

mit lcc32 habe ich schon gute Erfahrungen gemacht

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Michael B. schrieb:
> Völliger Quatsch, er will ein Commandline-Programm, keine
> Windows-Oberfläche.
Auch das geht ganz wunderbar mit dem QtCreator. Oh, und die Oberflaeche 
koennte man sogar unter Linux nutzen.
Wenn man keine Ahnung hat, einfach mal Kresse halten!

von Hmmm (Gast)


Lesenswert?

Felix U. schrieb:
> Bei read/write stimmt es schlicht nicht, die sind POSIX und gibt es
> dementsprechend auch.

Die funktionieren allerdings unter Windows nicht auf Sockets.

> recv/send sind auch Teil der Berkeley API und sollten auch unter Unix
> verwendet werden, dafür sind sie ja da.

Sowohl read()/write() als auch recv()/send() sind erlaubt, denn auch 
Sockets sind FDs.

Es kann sogar passieren, dass stdin und stdout Sockets sind, z.B. beim 
Start durch inetd.

von X4U (Gast)


Lesenswert?

Andi schrieb:
> Könnt ihr mir einen einfachen Weg für meine Zwecke weisen?

Bin jetzt so eher der embedded C Gelegenheitsprogger aber vielleicht 
hilft es:

Für Windows nutze ich Pelles C Compiler. Ist so schön simpel und für 
Commandline gibt es eine Vorlage.

von Andi (Gast)


Lesenswert?

Erstmal danke für die vielen Varianten ... viele Wege führen nach Rom ;)

Habe jetzt viel Lesestoff für die nächsten Tage.

cython und pypy werde ich auf jeden Fall mal ausprobieren.

nicht"Gast" schrieb:
> Bist du dir sicher, dass du das nicht einfach nur falsch machst?

Ha! Nein natürlich nicht.
Andersrum: Ich bin mir sicher, dass ich in python vieles falsch mache ;)

> Gerade bei Python kann man als alter C Programmierer viel in der
> Performance versauen. Viele Dinge werden in Python anders gelöst und
> sind im C-Style deutlich langsamer.

Da gebe ich dir 100%ig recht.
Mein ständiger Kampf wenn ich mit python arbeite ;)
Trotzdem mag ich die Sprache recht gerne...

Allerdings ist gerade der kritische Teil sehr einfach gestrickt.

Zur Erklärung: Es ist eine relativ einfache Server-Client Applikation.
Der Server läuft auf einer Arm mit FreeRTOS und lwip im Raw-Modus.
Der Client auf einem PC und eben momentan in Python.

Client:
- Daten aus Datei auslesen
- Daten senden.
- Empfangene Daten einlesen.
- Und in eine andere Datei schreiben.

Zur Simulation habe ich einen einfachen Server auch in Python am Laufen:
- Daten empfangen und gleich wieder senden (quasi Echomodus)

Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec.
Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec.

Momentan ausreichend, da die Zielhardware aktuell nicht mehr als 
50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren 
500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern 
;)

von Stefan F. (Gast)


Lesenswert?

Windows 10 enthält ein komplettes Linux Subsystem, man muss es nur 
aktivieren.  Ich arbeite aber trotzdem immer noch mit Cygwin weil 
Openssh in diesem neuen Subsystem nur eingeschränkt funktioniert.

von Nop (Gast)


Lesenswert?

asdfasd schrieb:
> Ich verstehe nicht, warum immer wieder Cygwin empfohlen wird - das
> Teil ist nen einziger Hack.

Zum Entwickeln mag ich das ganz gerne, insbesondere weil ich nicht 
dauernd Linux hochfahren muß, nur um zu checken, ob es auch mit Linux 
durchcompiliert. Und ich habe keine Lust, dafür jetzt mit VMs 
herumzufummeln.

Außerdem bietet Cygwin auch GDB im Terminal, den ich hin und wieder mal 
nutze. Meistens bei vertrackten Segfaults, deren Ursache nicht auf 
Anhieb ersichtlich ist.

Eine Einschränkung bei Cygwin ist allerdings, daß die sanitizer-Optionen 
von GCC nicht funktionieren. Das geht nur mit nativem Linux. Schade 
eigentlich, denn die sind für Test/Debug-Runs sehr nützlich.

Oder auch, um mal eben schnell kleinere Linuxprogramme ans Laufen zu 
bringen.

von Fabian F. (fabian_f55)


Lesenswert?

Tcp-Verbindungen in Windows geht relativ einfach mit Visual Studio mit 
dem WinPcap-Treiber.https://www.winpcap.org/
Für daten lesen gibts jede Menge Beispiele vür MS Vs

von Sven L. (sven_rvbg)


Lesenswert?

Stefan U. schrieb:
> Windows 10 enthält ein komplettes Linux Subsystem, man muss es nur
> aktivieren.  Ich arbeite aber trotzdem immer noch mit Cygwin weil
> Openssh in diesem neuen Subsystem nur eingeschränkt funktioniert.

Tolle Info!

Hier steht mehr: 
https://msdn.microsoft.com/de-de/commandline/wsl/install_guide

von nicht"Gast" (Gast)


Lesenswert?

Andi schrieb:
> Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec.
> Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec.
>
> Momentan ausreichend, da die Zielhardware aktuell nicht mehr als
> 50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren
> 500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern

Ach ja, ich hätte echt gerne auch mal wieder so viel Zeit auf Arbeit um 
mich Nichtigkeiten widmen zu können :)

War kein Witz. ich bin wirklich neidisch.

von (prx) A. K. (prx)


Lesenswert?

asdfasd schrieb:
> Naja, ähnlich ;-) Man muss schon einiges ändern: aus dem Kopf (ist schon
> ne Weile her): WSAStartup/WSACleanup am Anfang/Ende, nen Socket ist kein
> int, statt read/write/close recv/send/closesocket, anderes
> Errorhandling.

Socket-Programme so zu schreiben, dass sie sowohl mit Win32 als auch mit 
Linux funktionieren ist dennoch kein echtes Problem.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Andi schrieb:
> Zur Erklärung: Es ist eine relativ einfache Server-Client Applikation.
> Der Server läuft auf einer Arm mit FreeRTOS und lwip im Raw-Modus.
> Der Client auf einem PC und eben momentan in Python.
>
> Client:
> - Daten aus Datei auslesen
> - Daten senden.
> - Empfangene Daten einlesen.
> - Und in eine andere Datei schreiben.
>
> Zur Simulation habe ich einen einfachen Server auch in Python am Laufen:
> - Daten empfangen und gleich wieder senden (quasi Echomodus)
>
> Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec.
> Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec.
Arbeitest du mit dem threading-Modul?
Falls ja: Tausch das mal mit dem multiprocessing-Modul.
Das threading-Modul laeuft immer im Kontext des Pythoninterpreters, die 
Threads koennen vom OS nicht auf verschiedene Kerne aufgeteilt werden. 
Mit dem multiprocessing-Modul geht das.
Am Anfang einmal die Datei einlesen und dann:
1. Prozess: Daten senden
2. Prozess: Daten empfangen
3. Prozess: Daten in Datei schreiben
Zur Kommunikation zwischen den Prozessen kannst du Pipes oder Queues 
nutzen:
https://docs.python.org/3.6/library/multiprocessing.html#pipes-and-queues

von Christopher J. (christopher_j23)


Lesenswert?

Andi schrieb:
> - Dateien schreiben/lesen/manipulieren
> - Daten über TCP-sockets schicken und empfangen (als Client).

Ich würde für sowas auf jeden Fall noch Go als Sprache in Erwägung 
ziehen. Das ist fast so schnell wie C, hat eine mächtige 
Standard-Library und cross-compiling funktioniert auch tadellos. Alles 
landet in einer einzigen Binary (inkl. der Runtime), ohne dass du 
irgendwelche externen DLLs oder eine JVM benötigst. Coroutinen für 
asynchrone IO sind ebenfalls mit dabei, so dass man relativ einfach 
Prozesse parallelisieren kann. Die Sprache an sich ist trotzdem sehr 
schlank und wenn du Python magst und C kennst, dann wird dir Go sicher 
gefallen.

von Sheeva P. (sheevaplug)


Lesenswert?

Skyper schrieb:
> Ich werfe mal C++ mi Qt ins Rennen...

Widerspruch! C++, na klar -- aber ein GUI-Framework wie Qt für eine 
reine Konsolenanwendung?

> Nachteil:
> - Das Framework ist schon ziemlich "fett"
> - Nicht wirklich "Keep it simple"

*Ein GUI-Framework für eine Konsolenanwendung?*

von Sheeva P. (sheevaplug)


Lesenswert?

Andi schrieb:
> Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec.

Wenn Du eher kleine Frames versendest, ist das vollkommen normal, denn 
dann steigt der Overhead des Protokolls.

> Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec.

Wenn Du mehr zu Deiner Applikation und Deinem Protokoll sagen kannst, 
wird das sicher helfen.

> Momentan ausreichend, da die Zielhardware aktuell nicht mehr als
> 50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren
> 500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern
> ;)

Naja, wenn Du entsprechend viele Sensoren hast, und je nachdem, was Du 
auf diesem PC machst... Wie gesagt: vielleicht sagst Du mal ein bisschen 
mehr über Anwendungsfall, Applikation, und Protokoll. ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Nop schrieb:
>> ... Cygwin ...
>
> Zum Entwickeln mag ich das ganz gerne, insbesondere weil ich nicht
> dauernd Linux hochfahren muß, nur um zu checken, ob es auch mit Linux
> durchcompiliert. Und ich habe keine Lust, dafür jetzt mit VMs
> herumzufummeln.
>
> Außerdem bietet Cygwin auch GDB im Terminal, den ich hin und wieder mal
> nutze.

Docker?!

von Stefan F. (Gast)


Lesenswert?

> Widerspruch! C++, na klar -- aber ein GUI-Framework wie
> Qt für eine reine Konsolenanwendung?

Und schon wieder jemand, der Qt nur als GUI Framework kennt.

Tatsächlich ist die Qt GUI Komponente ein optinaler Teil von Qt. Die 
anderen Komponenten kann man sehr gut auf der Kommandozeile nutzen. 
Gerade für Netzwerk Anwendungen stellt Qt viele hilfreiche Sachen 
bereit.

Das Tutorial von meinem Webserver zeigt, wie man Qt in Konsole 
Anwendungen nutzt: http://stefanfrings.de/qtwebapp/index.html

Das Framework ist übrigen nicht "ziemlich fett". Die Java Runtime und 
.NET sind wesentlich umfangreicher. Abgesehen davon insteressiert das 
heutzutage niemanden mehr, der Geld für Softwareentwicklung ausgibt.

In den 90er Jahren gab es mal eine Firma, die haben es geschafft, ein 
Unix ähnliches Betriebssystem mit grafischem Desktop, Dateimanager, 
Email Client und Web Browser auf nur 2 Disketten zu packen. Das war 
damals noch cool, heute interessiert es niemanden mehr.

Wir leben in einer Zeit, wo handelsübliche Mikrocontroller (keine 
Exoten) schon mit 1MB internem Flash Speicher zu haben sind und bei PC's 
zig MB für UEFI verballert werden. Fotos werden standarmäßig mit 
12Megapixel und geringer Kompression gespeichert und bei Webseiten 
scheint es keine Sau mehr zu interessieren, ob der Download einer 
einzelnen Seite ein paar zig kB oder 2MB umfasst.

Die Maßeinheit "kiloByte" verliert an Bedeutung. Viele Laien wissen 
nichtmal, was das bedeutet. Sie kennen nur Megabytes und Gigabytes.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Sheeva P. schrieb:
> Widerspruch! C++, na klar -- aber ein GUI-Framework wie Qt für eine
> reine Konsolenanwendung?
Ich haette gedacht, dass gerade Du es besser weisst :(
Man muss damit doch keine GUI basteln. Die Klassen (Netzwerk, Seriell, 
Bluetooth, usw.) kann man doch auch ganz ohne GUI nutzen.

Beispiel:
Qt Serial Port Examples - Command Line Enumerator Example
http://doc.qt.io/qt-5/qtserialport-cenumerator-example.html

von Kommandozeile vor dem Frühstück für Alle! (Gast)


Lesenswert?

> Client:
> - Daten aus Datei auslesen
> - Daten senden.
> - Empfangene Daten einlesen.
> - Und in eine andere Datei schreiben.
>
> Zur Simulation habe ich einen einfachen Server auch in Python am Laufen:
> - Daten empfangen und gleich wieder senden (quasi Echomodus)

dieser Beschreibung nach also nichts was NetCat (nc.exe?) nicht schon 
kann.
Warum also doch eigene Quellcode (Erstellungs- & Wartungsaufwand) und 
Binary (Testaufwand)?
Und: wie schlägt sich nc durchsatzmässig denn so im Vergleich?

von Rolf M. (rmagnus)


Lesenswert?

Felix U. schrieb:
> Windows implementiert berkeley sockets. Für die socket-API sind sie
> sogar ausnahmsweise vom Großbuchstaben am Anfang der Funktion abgerückt.
> Die Funktionen heißen also nicht etwas anders sondern genau gleich - der
> einzige Unterschied ist, dass man vorher WSAStartup callen muss.

Es gibt schon noch ein paar mehr Unterschiede. Beispielsweise heißt es 
ioctlsocket() statt ioctl(). select() funktioniert im Gegensatz zu Unix 
nur mit Sockets und nix anderem. Fehlerhandling ist auch anders: Bei den 
original Berkley-Sockets bekommt man den Fehler in errno, bei Windows 
muss man WSAGetLastError() aufrufen, und auch die Bezeichnungen für die 
Fehler heißen allesamt anders.

Kaj G. schrieb:
> Man muss damit doch keine GUI basteln. Die Klassen (Netzwerk, Seriell,
> Bluetooth, usw.) kann man doch auch ganz ohne GUI nutzen.

Ja, und man muss die GUI-Lib von Qt dann auch gar nicht erst dazulinken. 
Seit Qt4 (oder war es schon bei Qt3?) ist es schließlich nicht mehr eine 
einzelne große Bibliothek, sondern in mehrere Komponenten aufgeteilt 
(wie z.B. Core, Netzwerk, XML, GUI, SQL, Webbrowser, Multimedia u.s.w.).

Stefan U. schrieb:
> Das Tutorial von meinem Webserver zeigt, wie man Qt in Konsole
> Anwendungen nutzt: http://stefanfrings.de/qtwebapp/index.html

Wichtig für Konsolen-Anwendungen sind dabei, wenn man QMake benutzt, die 
Einstellungen:
1
QT -= gui
2
CONFIG += console

Das erste sorgt dafür, dass keine GUI-Bibliothek gelinkt wird, das 
zweite dafür, dass es auch als Konsolen-Anwendung gebaut wird (da 
Windows da ja aus unverständlichen Gründen Unterschiede macht).

von Dirk B. (dirkb2)


Lesenswert?

Andi schrieb:
> Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec.
> Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec.

Sende einfach mal Testdaten aus dem RAM, Ohne Datei -öffnen, -lesen
Ebenso brauchst du die empfangenen Daten nicht abspeichern.

Wird es dadurch schneller?


Bei http://www.zotteljedi.de/ gibt es auch viele Informationen zu 
sockets.

von Andi (Gast)


Lesenswert?

nicht"Gast" schrieb:
> Ach ja, ich hätte echt gerne auch mal wieder so viel Zeit auf Arbeit um
> mich Nichtigkeiten widmen zu können :)
> War kein Witz. ich bin wirklich neidisch.

Wenn du das Erreichen der Projekt-Zielvorgaben als Nichtigkeit 
bezeichnen kannst, bin ich neidisch auf Deinen Job ;)


Kaj G. schrieb:
> Arbeitest du mit dem threading-Modul?
>...
> Mit dem multiprocessing-Modul geht das.

Nein, ich habe bisher nur ein paar Versuche mit coroutinen und asyncio 
gemacht.
Dabei hatte ich allerdings das Problem dass ich das Senden und Empfangen 
nicht auf 2 Routinen aufsplitten konnte.

Ja, da waren sie wieder meine Python-Schwächen ;)

Aber eigentlich brauche ich das nicht, da die Datenmenge in beide 
Richtungen identisch ist. Ich muss also nur dafür sorgen dass die 
Zielhardware ein wenig mehr Daten kriegt um die Latenzzeiten 
auszugleichen.

Sheeva P. schrieb:
> Wenn Du eher kleine Frames versendest, ist das vollkommen normal, denn
> dann steigt der Overhead des Protokolls.

Das ist klar.
Aber auch wenn ich grössere Frames nehme steigt der Durchsatz nicht 
wirklich großartig an.

> Naja, wenn Du entsprechend viele Sensoren hast, und je nachdem, was Du
> auf diesem PC machst... Wie gesagt: vielleicht sagst Du mal ein bisschen
> mehr über Anwendungsfall, Applikation, und Protokoll. ;-)

Am PC passiert sonst nicht wirklich wesentliches mit den Daten.
Die eigentlich Arbeit macht die Zielhardware.

Kommandozeile vor dem Frühstück für Alle! schrieb:
> dieser Beschreibung nach also nichts was NetCat (nc.exe?) nicht schon
> kann.

Für diesen Test hätte nc wahrscheinlich gereicht (wenn ich daran gedacht 
hätte) ;)

> Warum also doch eigene Quellcode (Erstellungs- & Wartungsaufwand) und
> Binary (Testaufwand)?

Soo aufwändig war das Erstellen der Testprogramme unter Linux nicht 
wirklich.

Die Entscheidung ist doch: Kann ich mit Python weiterarbeiten oder muss 
ich auf C umsteigen. Beides parallel zu machen habe ich nicht vor ;)

> Und: wie schlägt sich nc durchsatzmässig denn so im Vergleich?

Meine kleinen C-Programme unter Linux in einer VBOX zeigen dass ich 
schnell genug werde.
Tests auf einer echten Linuxmaschine stehen allerdings noch aus.
Aber wenns in der VBOX schon reicht, sollte es mit nativen 
Windowsprogrammen erst recht klappen.

Ich mag Python aber trotzdem noch nicht aufgeben und werde meine 
Programme aufräumen, aufs wesentlich reduzieren und hier reinstellen.
Vielleicht mag ja einer der Pythonspezialisten mal drüberschauen und 
meine Lücken aufdecken;)

Wird aber ein paar Tage dauern...

Danke einstweilen noch einmal für die vielen Anregungen!

von bastel_ (Gast)


Angehängte Dateien:

Lesenswert?

Ich habe vor >10 Jahren mal Code geschrieben, der TCP Zeug macht und 
sich im Visual Studio und mit dem gcc kompilieren lässt. Als Anhang ein 
Tool, das Daten aus einer TCP Verbindung liest und in eine Datei 
schreibt. Das ganze mit select() und so. Ist von 2014, der olle Code 
funktionierte immer noch :)

in scanner.c wird die Winsock initialisiert/runtergefahren, ansonsten in 
s400w ein bissel was mit #ifdef (oopensocket) umgebogen. select() selber 
ist für Windows und Unix identisch.

von nicht"Gast" (Gast)


Lesenswert?

Andi schrieb:
> nicht"Gast" schrieb:
>> Ach ja, ich hätte echt gerne auch mal wieder so viel Zeit auf Arbeit um
>> mich Nichtigkeiten widmen zu können :)
>> War kein Witz. ich bin wirklich neidisch.
>
> Wenn du das Erreichen der Projekt-Zielvorgaben als Nichtigkeit
> bezeichnen kannst, bin ich neidisch auf Deinen Job ;)

Das deine Vorgaben strenger sind konnte ja keiner Ahnen. Du hattest was 
von 50 MBit geschrieben, die der Controller kann.

Welche Geschwindigkeiten sollst du denn erreichen?

von Type Pun Intended (Gast)


Lesenswert?

Gibt es für Python eigentlich einen Profiler, dass man schauen kann, wo 
die Zeit verloren geht?

von Andi (Gast)


Lesenswert?

nicht"Gast" schrieb:
> Das deine Vorgaben strenger sind konnte ja keiner Ahnen. Du hattest was
> von 50 MBit geschrieben, die der Controller kann.
>
> Welche Geschwindigkeiten sollst du denn erreichen?

Ich habe geschrieben 'aktuell':

Andi schrieb:
> Momentan ausreichend, da die Zielhardware aktuell nicht mehr als
> 50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren
> 500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern ;)

Das heißt dass die Jungs in der Hardwareabteilung auch noch Gas geben 
müssen (und das auch tun)

;)

von Markus (Gast)


Lesenswert?

Wenn's spartanisch sein darf und 32-bit reichen:
http://www.delorie.com/djgpp/

(größere Projekte würde ich damit nicht aufsetzen wollen, aber für 
quick&dirty ausreichend)

von Karl Käfer (Gast)


Lesenswert?

Kaj G. schrieb:
> Sheeva P. schrieb:
>> Widerspruch! C++, na klar -- aber ein GUI-Framework wie Qt für eine
>> reine Konsolenanwendung?
> Ich haette gedacht, dass gerade Du es besser weisst :(

Trotzdem ist es am Ende so, daß Qt im Wesentlichen ein GUI-Framework ist 
und die Non-GUI-Teile, auch wenn man sie standalone verwenden kann, vor 
allem deswegen hineingebaut wurden, um ein konsistenteres, einfacheres 
Handling im Zusammenspiel mit den GUI-Teilen zu haben. Die andere 
Alternative wäre wohl gewesen, die damals bereits vorhandenen Teile von 
Qt an die STL anzupassen.

von Karl Käfer (Gast)


Lesenswert?

Andi schrieb:
> Die Entscheidung ist doch: Kann ich mit Python weiterarbeiten oder muss
> ich auf C umsteigen. Beides parallel zu machen habe ich nicht vor ;)

Dabei ist das gar nicht so schwierig. Du könntest

 - die lahmen Teile Deines Python-Programms durch eine Extension 
ersetzen,
   die wahlweise in C (siehe Python-Dokumentation oder Cython) oder in 
C++
   (siehe dazu die C++-Bibliothek boost::python) geschrieben sein kann

 - Dein Python-Programm mit nuitka in C++ und darüber in nativen Code
   übersetzen

 - einen anderen Python-Interpreter wie Jython oder Pypy benutzen

> Ich mag Python aber trotzdem noch nicht aufgeben und werde meine
> Programme aufräumen, aufs wesentlich reduzieren und hier reinstellen.
> Vielleicht mag ja einer der Pythonspezialisten mal drüberschauen und
> meine Lücken aufdecken;)

Wahrscheinlich wäre es nicht die schlechteste Idee, zunächst einmal die 
Performanceengpässe in Deinem Code zu identifizieren, sprich: einen der 
vorhandenen Python-Profiler oder ggf. gprof zu benutzen.

von Stefan F. (Gast)


Lesenswert?

Für mich als hauptsächlicher Java Programmierer fühlt sicht Qt viel 
gewohnter an, als stl. Das ist bei mir der Hauptgrund, warum ich es 
gerne nutze.

> vor allem deswegen hineingebaut wurden, um ein konsistenteres,
> einfacheres Handling im Zusammenspiel mit den GUI-Teilen zu haben.

Ja das sehe ich auch so. Ich kenne Qt seit Version 1.irgendwas. 
Allerdings ist das kein nachteil (mehr). Da sind viele nützliche Sachen 
drin, die abseits der GUI prima funktionieren. Der Verzicht auf die GUI 
macht hier nichts komplizierter, als nötig.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Type Pun Intended schrieb:
> Gibt es für Python eigentlich einen Profiler, dass man schauen kann, wo
> die Zeit verloren geht?
Liefert Python mit:

27.4. The Python Profilers
https://docs.python.org/3.6/library/profile.html#the-python-profilers

Karl Käfer schrieb:
> Trotzdem ist es am Ende so, daß Qt im Wesentlichen ein GUI-Framework ist
> und die Non-GUI-Teile, auch wenn man sie standalone verwenden kann, vor
> allem deswegen hineingebaut wurden, um ein konsistenteres, einfacheres
> Handling im Zusammenspiel mit den GUI-Teilen zu haben.
Und das spielt was fuer eine Rolle? Es gibt Module, die man ohne GUI 
verwenden kann. Fertig. Warum es diese Module in dem Framework gibt, 
ist doch voellig schnuppe. Sie sind da, und man kann sie verwenden. Und 
die Qt Doku ist, verglichen mit anderen Frameworks, wirklich 
erstklassig.

von Stefan F. (Gast)


Lesenswert?

Ich denke, er wollte nur den historischen Grund nennen, warum Qt häufig 
noch als GUI Framework bezeichnet wird.

von Sheeva P. (sheevaplug)


Lesenswert?

Kaj G. schrieb:
> Karl Käfer schrieb:
>> Trotzdem ist es am Ende so, daß Qt im Wesentlichen ein GUI-Framework ist
>> und die Non-GUI-Teile, auch wenn man sie standalone verwenden kann, vor
>> allem deswegen hineingebaut wurden, um ein konsistenteres, einfacheres
>> Handling im Zusammenspiel mit den GUI-Teilen zu haben.
>
> Und das spielt was fuer eine Rolle? Es gibt Module, die man ohne GUI
> verwenden kann. Fertig.

Richtig... aber um die zu benutzen, darf man sich erstmal durch n 
"Getting Started"-Tutorials fräsen, deren wesentliche Gemeinsamkeit was 
ist? Genau: die Entwicklung von grafischen Benutzeroberflächen.

Insofern sind die betreffenden Module zwar vorhanden, und ein erfahrener 
Qt-Entwickler kann und wird sie vielleicht benutzen oder vielleicht auch 
nicht. Aber sich zunächst einmal in ein GUI-Framework einzuarbeiten, um 
letztlich dann doch mit einzelnen Bibliotheken daraus eine kleine 
CLI-Applikation zu schreiben: solange man nicht vorhat, das erworbene 
Wissen noch anderweitig zu nutzen oder die Sache eher als Selbstzweck 
betreibt, erscheint mir das nicht besonders zielführend.

Im Übrigen scheint mir, daß die klassischen GUIs langsam aussterben. 
Viele Anwendungen, die man vor zehn Jahren mit einer GUI gemacht hätte, 
werden heutzutage als Web-GUIs umgesetzt -- oft sogar lokale. In 
Unternehmen, wo Applikationen am Liebsten zentral deployt, gepflegt und 
verwaltet werden, sind klassische GUIs häufig sogar ein KO-Kriterium, 
wenn ein Wettbewerber eine schicke WebApp anbietet. Insofern stellt sich 
je nach Umfeld ohnehin die Frage, wie sinnvoll es heute noch ist, sich 
in ein umfangreiches GUI-Framework einzuarbeiten. YMMV. ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Karl Käfer schrieb:
> Wahrscheinlich wäre es nicht die schlechteste Idee, zunächst einmal die
> Performanceengpässe in Deinem Code zu identifizieren, sprich: einen der
> vorhandenen Python-Profiler oder ggf. gprof zu benutzen.

Korrekt. Ergänzend dazu möchte ich auf den wichtigsten Merksatz zum 
Thema Performanceoptimierung hinweisen: "Measure, don't guess" (Kirk 
Pepperdine).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.