Hallo Liste!
Ich habe folgendes Code-Beispiel (Buch: C und Linux) für einen einfachen "Universal-Client" (Arbeitsweise ähnlich Terminal-Programm) für C unter Linux gefunden:
#include <stdio.h> #include <unistd.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h>
int main(int argc, char *argv[]) { static char buffer[256]; int sock_fd, err, length, port; struct sockaddr_in server_addr; fd_set input_fdset;
if (argc != 3) { fprintf(stderr, "Usage: connect ip-addr port\n"); return(1); }
if (sscanf(argv[2], "%d", &port) != 1) { fprintf(stderr, "connect: bad argument '%s'\n", argv[2]); return(1); }
sock_fd = socket(PF_INET, SOCK_STREAM, 0); if (sock_fd == -1) { perror("connect: Can't create new socket"); return(1); }
server_addr.sin_family = AF_INET; server_addr.sin_port = htons(port); err = inet_aton(argv[1], &(server_addr.sin_addr)); if (err == 0) { fprintf(stderr, "connect: Bad IP-Address '%s'\n", argv[1]); return(1); }
err = connect(sock_fd, &server_addr, sizeof(struct sockaddr_in)); if (err == -1) { perror("connect: connect() failed"); return(1); }
while (1) { FD_ZERO(&input_fdset); FD_SET(STDIN_FILENO, &input_fdset); if (select(sock_fd+1, &input_fdset, NULL, NULL, NULL) == -1) perror("connect: select() failed"); if (FD_ISSET(STDIN_FILENO, &input_fdset)) { if (fgets(buffer, 256, stdin) == NULL) { printf("connect: Closing socket.\n"); break; } length = strlen(buffer); send(sock_fd, buffer, length, 0); } else { length = recv(sock_fd, buffer, 256, 0); if (length == 0) { printf("Connection closed by remote host.\n"); break; } write(STDOUT_FILENO, buffer, length); } } close(sock_fd); return(0); }
Wenn ich den Code kompiliere und linke (SUSE 10.0 wie auch Knoppix 5.1.1), erscheint folgende Warnung:
./client.c:44: Warnung: Übergabe des Arguments 2 von "connect" von inkompatiblem Zeigertyp
bzw. etwas im Sinne von
passing argument 2 [...] incompatible pointer type
Beim Start des Progs erscheint keinerlei Fehlermeldung. Sowohl socket() als auch connect() scheinen zu funktionieren. Allerdings kommt keine Ausgabe der Verbindungsbestätigung. Im Buch wird beispielhaft eine Verbindung zu einem FTP-Server aufgebaut. Dort erscheint dann
220 toshi.at-home FTP server [...]
Es können Eingaben getätigt werden, die Antworten des Servers werden ausgegeben. So leider nicht bei mir...
Was habe ich übersehen?
Besten Dank vorab & Grüße, Kai
Am Mittwoch, 7. März 2007 09:43 schrieb Kai-Micael Preiß:
Hallo Liste!
Ich habe folgendes Code-Beispiel (Buch: C und Linux) für einen einfachen "Universal-Client" (Arbeitsweise ähnlich Terminal-Programm) für C unter Linux gefunden:
Ich empfehle, wenn es denn schon in C sein muss, einfach libggz-dev zu installieren und über #include <ggz.h> fd = ggz_make_socket(GGZ_SOCK_CLIENT, 22, "localhost"); die Sache mächtig zu vereinfachen und auch gleich noch Unterstützung für IPv6, SSL/TLS und dergleichen drin zu haben und sich nicht um Kompatibilität mit BSD oder alternativen Washington'schen Systemen beschäftigen zu müssen.
Wer auch immer den Beispielquelltext erstellt hat, hat nicht unbedingt Kompetenz bewiesen. Das sizeof() führt man auf den Variablennamen aus, nicht auf den Datentyp, denn dieser kann sich evtl. mal ändern (z.B. 32->64 bit) und dann hat man zwei Stellen anstatt nur einer, an der man das ändern muss und eventuell vergisst.
Der Typfehler kann über ein Casting behoben werden. Also (struct sockaddr*)server_addr verwenden. Aber wie gesagt, ich würde mir nicht all die Probleme einhandeln wollen, die man bekommt, wenn man Netzwerkcode auf der Ebene selbst in die Hand nimmt.
Josef
-----Original Message----- From: Josef Spillner [mailto:2005@kuarepoti-dju.net] Sent: Wednesday, March 07, 2007 10:16 AM To: kai-micael.preiss@tu-dresden.de; Linux-User-Group Dresden Subject: Re: C und Netzwerkprog
Am Mittwoch, 7. März 2007 09:43 schrieb Kai-Micael Preiß:
Hallo Liste!
Ich habe folgendes Code-Beispiel (Buch: C und Linux) für einen einfachen "Universal-Client" (Arbeitsweise ähnlich Terminal-Programm) für C unter Linux gefunden:
Ich empfehle, wenn es denn schon in C sein muss, einfach libggz-dev zu installieren und über #include <ggz.h> fd = ggz_make_socket(GGZ_SOCK_CLIENT, 22, "localhost"); die Sache mächtig zu vereinfachen und auch gleich noch Unterstützung für IPv6, SSL/TLS und dergleichen drin zu haben und sich nicht um Kompatibilität mit BSD oder alternativen Washington'schen Systemen beschäftigen zu müssen.
Wer auch immer den Beispielquelltext erstellt hat, hat nicht unbedingt Kompetenz bewiesen. Das sizeof() führt man auf den Variablennamen aus, nicht auf den Datentyp, denn dieser kann sich evtl. mal ändern (z.B. 32->64 bit) und dann hat man zwei Stellen anstatt nur einer, an der man das ändern muss und eventuell vergisst.
Der Typfehler kann über ein Casting behoben werden. Also (struct sockaddr*)server_addr verwenden. Aber wie gesagt, ich würde mir nicht all die Probleme einhandeln wollen, die man bekommt, wenn man Netzwerkcode auf der Ebene selbst in die Hand nimmt.
Josef
---------
Hallo Josef,
erstmal danke für die Infos!
Meinereiner versucht sich grad ansatzweise in die Netzwerkprog einzufitzen. Anscheinend findet man hier aber nur sehr schwer vernünftige Literatur... Was empfiehlst Du denn statt C? Zu C++ habe ich bezgl. Netzwerkprog überhaupt nichts finden können.
Was das Casten angeht: Warnung ist weg. Allerdings erhalte ich immer noch keinerlei Ausgaben... (Ich hab den Adress-Operator drin gelassen, da ja als Übergabewert eine Adresse erwartet wird. Fehlt bei Dir... Korrekt?)
Vielleicht als Hintergrundinfo: wir sind dabei, unser Sim-Labor zu "überarbeiten". Schritt 1 soll ein Traffic Generator sein, der Positionsdaten ins Netz schießt, die von einer 2.Anwendung empfangen und verarbeitet werden.
Danke & Gruß, Kai
1.) telnet ist eine art universeller client: telnet <host> <port> Wenn das nicht tut, kann auch nichts anderes tun (bei TCP)
2. Als Literatur kann ich nur waermstens "Unix Network Programming" von Stevens empfehlen. Da sind die ersten Beispiele auch deutlich einfacher (kein select()...)
Gruss
Frank
On 3/7/07, Kai-Micael Preiß preiss@ifl.tu-dresden.de wrote:
-----Original Message----- From: Josef Spillner [mailto:2005@kuarepoti-dju.net] Sent: Wednesday, March 07, 2007 10:16 AM To: kai-micael.preiss@tu-dresden.de; Linux-User-Group Dresden Subject: Re: C und Netzwerkprog
Am Mittwoch, 7. März 2007 09:43 schrieb Kai-Micael Preiß:
Hallo Liste!
Ich habe folgendes Code-Beispiel (Buch: C und Linux) für einen einfachen "Universal-Client" (Arbeitsweise ähnlich Terminal-Programm) für C unter Linux gefunden:
Ich empfehle, wenn es denn schon in C sein muss, einfach libggz-dev zu installieren und über #include <ggz.h> fd = ggz_make_socket(GGZ_SOCK_CLIENT, 22, "localhost"); die Sache mächtig zu vereinfachen und auch gleich noch Unterstützung für IPv6, SSL/TLS und dergleichen drin zu haben und sich nicht um Kompatibilität mit BSD oder alternativen Washington'schen Systemen beschäftigen zu müssen.
Wer auch immer den Beispielquelltext erstellt hat, hat nicht unbedingt Kompetenz bewiesen. Das sizeof() führt man auf den Variablennamen aus, nicht auf den Datentyp, denn dieser kann sich evtl. mal ändern (z.B. 32->64 bit) und dann hat man zwei Stellen anstatt nur einer, an der man das ändern muss und eventuell vergisst.
Der Typfehler kann über ein Casting behoben werden. Also (struct sockaddr*)server_addr verwenden. Aber wie gesagt, ich würde mir nicht all die Probleme einhandeln wollen, die man bekommt, wenn man Netzwerkcode auf der Ebene selbst in die Hand nimmt.
Josef
Hallo Josef,
erstmal danke für die Infos!
Meinereiner versucht sich grad ansatzweise in die Netzwerkprog einzufitzen. Anscheinend findet man hier aber nur sehr schwer vernünftige Literatur... Was empfiehlst Du denn statt C? Zu C++ habe ich bezgl. Netzwerkprog überhaupt nichts finden können.
Was das Casten angeht: Warnung ist weg. Allerdings erhalte ich immer noch keinerlei Ausgaben... (Ich hab den Adress-Operator drin gelassen, da ja als Übergabewert eine Adresse erwartet wird. Fehlt bei Dir... Korrekt?)
Vielleicht als Hintergrundinfo: wir sind dabei, unser Sim-Labor zu "überarbeiten". Schritt 1 soll ein Traffic Generator sein, der Positionsdaten ins Netz schießt, die von einer 2.Anwendung empfangen und verarbeitet werden.
Danke & Gruß, Kai
Lug-dd maillist - Lug-dd@mailman.schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
On Wed, Mar 07, 2007 at 10:30:29AM +0100, Kai-Micael Preiß wrote:
Hallo Josef,
erstmal danke für die Infos!
Meinereiner versucht sich grad ansatzweise in die Netzwerkprog einzufitzen. Anscheinend findet man hier aber nur sehr schwer vernünftige Literatur... Was empfiehlst Du denn statt C? Zu C++ habe ich bezgl. Netzwerkprog überhaupt nichts finden können.
Hallo,
ich empfehle dir Python. Eigentlich alle Netzwerkprotokolle werden unterstützt: pop3, imap, ldap, smtp, http ...
Reine Socketprogrammierung ist natürlich auch möglich.
Du sparst dir damit eine Menge Zeit.
Eigenwerbung: http://www.thomas-guettler.de/vortraege/python/einfuehrung.html
Gruß, Thomas
Kai-Micael Preiß preiss@ifl.tu-dresden.de writes:
Was kommt denn als Alternative zu C in Frage?
Perl?
Steffen
On 3/7/07, Steffen Schwigon schwigon@webit.de wrote:
Kai-Micael Preiß preiss@ifl.tu-dresden.de writes:
Was kommt denn als Alternative zu C in Frage?
Perl?
Naja, wenn es auf Performance ankommt (grosse Datenmengen usw), bleibt nur C/C++ als Alternative. Allerdings sollte man dann *auf jeden Fall* einen Memory-Checker wie valgrind (FOSS) oder Purify (IBM) einsetzen. Es passiert so leicht, einen Puffer zu ueberschreiben oder ein Objeckt zu frueh freizugeben oder ....
Gruss
Frank
On Wed, March 7, 2007 14:06, Frank Gerlach wrote:
On 3/7/07, Steffen Schwigon schwigon@webit.de wrote:
Perl?
Naja, wenn es auf Performance ankommt (grosse Datenmengen usw), bleibt nur C/C++ als Alternative.
Autsch.
Zum einen: C++ ist nicht unbedingt performant. Es kommt darauf an, welches Toolkit drumherum steht. Es hat das Potential schneller als Perl zu sein, aber das war es auch schon.
Zum zweiten: C ist auch nicht performant, wenn der Programmierer nicht genau weiss was er tut. Dafuer bietet kaum eine andere Sprache so viele Gelegenheiten sich ganz dicht auf Tuchfuehlung mit der libc so richtig grosse Loecher in den Fuss zu schiessen.
Allerdings sollte man dann *auf jeden Fall* einen Memory-Checker wie valgrind (FOSS) oder Purify (IBM) einsetzen. Es passiert so leicht, einen Puffer zu ueberschreiben oder ein Objeckt zu frueh freizugeben oder ....
Eben.
Solange das Problem ueberschaubar ist: irgendeine der hundert Scriptsprachen nehmen.
Wenn nicht: ein vernuenftiges Projekt mit Prototypen und Spec und ordentlicher Zeitplanung aufmachen.
Konrad
Konrad Rosenbaum schrieb:
Zum einen: C++ ist nicht unbedingt performant. Es kommt darauf an, welches Toolkit drumherum steht. Es hat das Potential schneller als Perl zu sein, aber das war es auch schon.
Zum zweiten: C ist auch nicht performant, wenn der Programmierer nicht genau weiss was er tut. Dafuer bietet kaum eine andere Sprache so viele Gelegenheiten sich ganz dicht auf Tuchfuehlung mit der libc so richtig grosse Loecher in den Fuss zu schiessen.
Man kann in jeder Programmiersprache langsamen und unsicheren Code schreiben.
Wenn nicht: ein vernuenftiges Projekt mit Prototypen und Spec und ordentlicher Zeitplanung aufmachen.
Wenn der Chef selbst Softwareentwickler ist: Prima! Gute Idee! Ansonsten: BWAHAHAHAHAHAHAHAHAHA! Viel Spaß dabei, das durchzusetzen.
Eric
On Wednesday 07 March 2007, Eric-Alexander Schaefer wrote:
Konrad Rosenbaum schrieb:
Wenn nicht: ein vernuenftiges Projekt mit Prototypen und Spec und ordentlicher Zeitplanung aufmachen.
Wenn der Chef selbst Softwareentwickler ist: Prima! Gute Idee!
(Und wie üblich: Softwareentwickler==gut, VB-Bastler=Katastrofe (mit "f", weil schlimmer).)
Ansonsten: BWAHAHAHAHAHAHAHAHAHA! Viel Spaß dabei, das durchzusetzen.
Was ich vergaß zu erwähnen (ich A*loch!): das Problem einen Manager zu überzeugen ist md-vollständig. Das Kürzel "md" steht hier für den "Monkey-Dance", den man aufführen muss. Es gibt da ein gutes Le(e|h)rvideo von Stevie B. ;-)
Konrad
-----Original Message----- From: lug-dd-bounces@mailman.schlittermann.de [mailto:lug-dd-bounces@mailman.schlittermann.de] On Behalf Of Konrad Rosenbaum Sent: Thursday, March 08, 2007 9:16 AM To: Linux-User-Group Dresden Subject: Re: C und Netzwerkprog
On Wednesday 07 March 2007, Eric-Alexander Schaefer wrote:
Konrad Rosenbaum schrieb:
Wenn nicht: ein vernuenftiges Projekt mit Prototypen und Spec und ordentlicher Zeitplanung aufmachen.
Wenn der Chef selbst Softwareentwickler ist: Prima! Gute Idee!
(Und wie üblich: Softwareentwickler==gut, VB-Bastler=Katastrofe (mit "f", weil schlimmer).)
Ansonsten: BWAHAHAHAHAHAHAHAHAHA! Viel Spaß dabei, das durchzusetzen.
Was ich vergaß zu erwähnen (ich A*loch!): das Problem einen Manager zu überzeugen ist md-vollständig. Das Kürzel "md" steht hier für den "Monkey-Dance", den man aufführen muss. Es gibt da ein gutes Le(e|h)rvideo von Stevie B. ;-)
Konrad
--------------------------------------
Lieben Dank für die motivierenden Worte ;) Die Netzwerkgeschichte ist ja letztlich nur ein kleiner Teil des Verbundes (wie beschrieben). Die Anmerkungen zum ursprünglichen Problem haben mir sehr weitergeholfen. Besten Dank dafür!!!
Die (Neu-)Konzeption des Sim-Verbundes ist wieder so 'ne (leidvolle) Geschichte für sich... Obige Kommentare kann ich insofern leider nur bestätigen :(
Grüße, Kai
On Wed, Mar 07, 2007 at 02:06:06PM +0100, Frank Gerlach wrote:
On 3/7/07, Steffen Schwigon schwigon@webit.de wrote:
Kai-Micael Preiß preiss@ifl.tu-dresden.de writes:
Was kommt denn als Alternative zu C in Frage?
Perl?
Naja, wenn es auf Performance ankommt (grosse Datenmengen usw), bleibt nur C/C++ als Alternative. Allerdings sollte man dann *auf jeden Fall* einen Memory-Checker wie valgrind (FOSS) oder Purify (IBM) einsetzen. Es passiert so leicht, einen Puffer zu ueberschreiben oder ein Objeckt zu frueh freizugeben oder ....
Bist du dir sicher das C schneller als eine Scriptsprache ist?
Meistens ist die Entwicklungsgeschwindigkeit einiges wichtiger, als der minimale Unterschied in der Laufzeit!
Bei Netzwerkprogrammierung ist C sicherlich nicht schneller, das Netzwerk wird wohl der Flaschenhals sein.
Perl würde ich nicht nehmen. Gerade heute habe ich mich damit wieder herumärgern müssen.
Einige Gründe warum ich Perl nicht mag: http://www.thomas-guettler.de/vortraege/programmierung/einfuehrung.html#perl...
Gruß, Thomas
guettli@thomas-guettler.de (Thomas Guettler) writes:
Perl würde ich nicht nehmen. Gerade heute habe ich mich damit wieder herumärgern müssen.
Einige Gründe warum ich Perl nicht mag: http://www.thomas-guettler.de/vortraege/programmierung/einfuehrung.html#perl...
Die URL hab ich letztens schon mal gelesen. Wenn ich mal Zeit habe, schreibe ich mal zu jedem Anschnitt eine Perl-Antwort. Vielleicht nehme ich's mir zum nächsten Perl-Mongers-Treffen vor. Mal sehen.
IMHO vergleichst Du dort 7 Jahre alten Perl-Stil (ohne "strict" und ohne CPAN) mit modernem Python-Stil.
In Perl hat sich aber so viel getan, dass fast alle Argumente nicht mehr gelten. CPAN vorausgesetzt. Aber Perl *ist* CPAN. Wenn ich an dieser Voraussetzung drehen kann, kann ich fast alles "widerlegen"[*].
Macht allerdings Mühe. Die Du Dir zugegebenermaßen schon gemacht hast. Respekt.
Ich sage übrigens nicht, dass Dein Python eine schlechte Wahl ist. Nur so als Hinweis, damit das hier nicht als Flamewar missverstanden wird.
Steffen
[*] Im wesentlichen bleibt die geschmackliche Präferenz der Syntax übrig, die aber ihren Sinn im Gesamtkontext der Sprache hat.
Hallo Steffen und andere,
On Thu, Mar 08, 2007 at 12:10:52PM +0100, Steffen Schwigon wrote:
guettli@thomas-guettler.de (Thomas Guettler) writes:
Perl würde ich nicht nehmen. Gerade heute habe ich mich damit wieder herumärgern müssen.
Einige Gründe warum ich Perl nicht mag: http://www.thomas-guettler.de/vortraege/programmierung/einfuehrung.html#perl...
Die URL hab ich letztens schon mal gelesen. Wenn ich mal Zeit habe, schreibe ich mal zu jedem Anschnitt eine Perl-Antwort. Vielleicht nehme ich's mir zum nächsten Perl-Mongers-Treffen vor. Mal sehen.
Das wäre sehr nett! Vielleicht gibt es auch ein paar Dinge die ich auf obiger Seite falsch dargestellt habe.
Macht allerdings Mühe. Die Du Dir zugegebenermaßen schon gemacht hast. Respekt.
Wenn ich während der Arbeit über etwas stolpere, dass mir an Perl gar nicht gefällt, schreibe ich mir auf die private Adresse eine kurze Email. Das wird dann irgendwann in die Seite eingebracht.
Ich sage übrigens nicht, dass Dein Python eine schlechte Wahl ist. Nur so als Hinweis, damit das hier nicht als Flamewar missverstanden wird.
Ich finde Perl auch nicht schlecht. Ich verwende es sogar öfters mal für einen Einzeiler.
Gruß, Thomas
Hallo Kai,
On Wed, Mar 07, 2007 at 12:11:01 +0100, Kai-Micael Preiss wrote:
Was kommt denn als Alternative zu C in Frage? Im Nachgang zu meiner Mail von vorhin: die vorhandene Sim-Umgebung laeuft unter SuSe Linux 5.3 und
Auf dem System wird man libggz wohl nicht installieren koennen (Josef?)
Ich weiss nicht, was Eure Sim-Umgebung koennen muss, aber reicht es nicht, sich mit den ueblichen Verdaechtigen netcat, hping2, rain, ... und Shellskripten zu beschaeftigen?
Gruss, Chris
Hallo Chris!
Was kommt denn als Alternative zu C in Frage? Im Nachgang zu meiner Mail von vorhin: die vorhandene Sim-Umgebung laeuft unter SuSe Linux 5.3 und
Auf dem System wird man libggz wohl nicht installieren koennen (Josef?)
Habe ich auch soeben festgestellen müssen (debian-package).
Ich weiss nicht, was Eure Sim-Umgebung koennen muss, aber reicht es nicht,
sich mit den ueblichen Verdaechtigen netcat, hping2, rain, ... und Shellskripten zu beschaeftigen?
Ziel ist's, die vorhandene Sim-Umgebung neu zu bauen, die im Wesentlichen aus zwei verschiedenen Radar-Applikationen, einem GhostPilot sowie dem erwähnten TrafficGenerator besteht. Hinzu kommt noch eine Schnittstelle für die Positionsdaten eines A320-Simulators. All das läuft momentan unter Linux 5.3, für die Radar-Apps sowie die zentrale Verkehrs-Sim sind wir auf die ODS-Toolbox (in einer uralten Version) angewiesen, die auf gut deutsch ein Schweinegeld kostet. Schritt 1 soll darin bestehen, den TrafficGenerator neu zu bauen (das gesamte Sim-Konzept soll in Perspektive neu gestrickt werden). Parallel sind wir auf die restlichen Apps angewiesen. Ergo muss der neue TG die generierten Daten übers Netz ans Radar senden können. Momentan wird unter Windows mit Java "rumgestümpert", da hier von einem anderen Projekt einige Zeilen Quellcode existieren. Für Echt-/Schnellzeitsimulationen ist Java IMHO allerdings zu langsam...
Weil soeben noch einige Mails reingekommen sind: für Perl ist das Projekt wohl zu komplex. Außerdem ist damit bei uns quasi keiner vertraut. @Frank: Danke für den Hinweis ob des Memory-Checkers!
Inwieweit nun die reine Datenübertragung über "externe"/bordeigene Linux-Tools sinnvoll realisiert werden kann, ohne dass die Performance in den Keller geht, kann ich momentan nicht beurteilen. Wir sprechen hier von einer Update-Rate von 1 Sekunde für mehrere hundert Flugzeuge im zu simulierenden Luftraum.
Gruß, Kai
Hallo nochmal,
Am Mittwoch, 7. März 2007 14:19 schrieb Kai-Micael Preiß:
Auf dem System wird man libggz wohl nicht installieren koennen (Josef?)
Habe ich auch soeben festgestellen müssen (debian-package).
Das Systemalter hatte ich nicht mit beachtet - da du ursprünglich von einer 10er-Version gesprochen hattest.
Es sollte sich aber mit etwas Glück dennoch compilieren lassen: http://mirrors.ibiblio.org/pub/mirrors/ggzgamingzone/ggz/0.0.14/libggz-0.0.1...
Leider hat SourceForge die Compile Farm vor kurzem eingestellt, da konnte man immer gut ältere Systeme austesten. Vermutlich wirst du auf TLS verzichten müssen (OpenSSL und GnuTLS haben garantiert eine andere API gehabt), und auch asynchrone DNS-Operationen sind erst mit neueren glibcs möglich. Die Grundfunktionalität sollte aber da sein.
Wenn es Probleme beim Compilieren gibt, bitte das komplette Fehlerlog an mich senden.
Ziel ist's, die vorhandene Sim-Umgebung neu zu bauen, die im Wesentlichen aus zwei verschiedenen Radar-Applikationen, einem GhostPilot sowie dem erwähnten TrafficGenerator besteht. Hinzu kommt noch eine Schnittstelle für die Positionsdaten eines A320-Simulators. All das läuft momentan unter Linux 5.3, für die Radar-Apps sowie die zentrale Verkehrs-Sim sind wir auf die ODS-Toolbox (in einer uralten Version) angewiesen, die auf gut deutsch ein Schweinegeld kostet.
Wenn die Anwendung sich wirklich nicht migrieren lässt, wäre das sehr hinderlich für eine Menge nützlicher Tools. Auch die Skriptsprachen waren vor 10 Jahren nicht das, was sie heute sind.
Momentan wird unter Windows mit Java "rumgestümpert", da hier von einem anderen Projekt einige Zeilen Quellcode existieren. Für Echt-/Schnellzeitsimulationen ist Java IMHO allerdings zu langsam...
Glaube keinem Benchmark, den du nicht selbst gefälscht hast :) Aber Java würde ich für solche Aufgaben tatsächlich nicht einsetzen.
Wir sprechen hier von einer Update-Rate von 1 Sekunde für mehrere hundert Flugzeuge im zu simulierenden Luftraum.
Irgendwo wurde vor kurzem so ein Zwischending von TCP und UDP vorgestellt, für solche Spezialanwendungen lohnt sich womöglich der Aufwand, dort mal nachzuforschen. Ich nehme an, dass es im Gegensatz zu Quake dem Unterfangen eher weniger zuträglich ist, wenn mal ein Paket verloren geht.
Josef
Hallo Kai,
ich kann da den folgenden Link empfehlen.
http://www.uvomatik.de/programmierung/sockdoc/index.html
Mit freundlichen Grüßen Rico
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Eric-Alexander Schaefer -
Frank Gerlach -
guettli＠thomas-guettler.de -
Josef Spillner -
Kai-Micael Preiß -
Konrad Rosenbaum -
Rico Schüller -
Steffen Schwigon