[C++/CLI] Callbacks

[Kati82]

Hallo,

ich würde gerne eine CALLBACK-FUNKTION programmieren, nur leider habe ich keinen blassen Schimmer wie das geht. Das Internet hat mir bis jetzt auch noch nix greifbares ausgespuckt. Kann mir jemand eventuell ne Link sagen, wo das übersichtlich erklärt wird?

Ich möchte nämlich bei meinem Socketprogramm mit WSAAsyncSelect arbeiten. Das hier habe ich bisher:

int wRet = WSAAsyncSelect(client, GetForegroundWindow(), WM_USER+1, (FD_ACCEPT | FD_READ | FD_WRITE | FD_CLOSE));


...


LRESULT CALLBACK CTcpTest::OnNotifyWSAAsyncSelect(HWND hWnd, UINT uMessage, WPARAM, LPARAM lParam)

{

...

}

Verständlicherweise kommt man nie in die Funktion OnNotifyWSAAsyncSelect. Ich muss noch irgendwie angeben, dass er bei solchen WSA-Events in diese Funktion reinspringen soll. Aber ich weiß weder wie, noch wo ich das machen muss. Etwa direkt vor dem WSAAsyncSelect? Als Form möchte ich mein bestehendes MainForm nehmen.

Kann mir bitte jemand weiterhelfen? Viele Dank im voraus.

Gruß Kati82

[Guybrush Threepwood]

Du musst die Funktion selber aufrufen wenn ein solcher Event eintritt.

Denn wie auch in der Doku zu WSAAsyncSelect steht, wird im Fall eines Netzwerk Events eine Nachricht (also die die du WSAAsyncSelect übergibst) an dein Programm gesendet.

Du musst die Nachricht abfangen und dann halt wie gewünscht darauf reagieren

[Kati82]

Wie jetzt? Ich dachte das WSAAsyncSelect ist dazu da, dass wenn eins von den genannten Sachen eintritt, das Programm in diesen Callback reinspringt, und das dort abhängig vom Event in die entsprechende Funktion reingesprungen wird.

Hab ich das bis dahin richtig verstanden?

Ich versuchs mal am Beispiel von Receive. Hab nen Socket erstellt WSAAsyncSelect gemacht und mich erfolgreich verbunden. Jetzt werde Daten zu meinem Socket gesendet. Das heißt ein Event müsste ausgelöst werden. Das Programm sollte jetzt in meine Notify-Funktion reinspringen, feststellen dass das Event ein FD_READ ist und damit in die Funktion zum lesen reinspringen. Mein Problem liegt jetzt also bei dem Event. Ich weiß nicht, wie ich das abfangen soll. Ich dachte, man macht das mit diesem Callback. Und ich dachte, ich muss dem Programm nur noch irgendwie verklickern, dass es im Falle eines solchen Events in diesen Callback reinspringen soll.

Bin jetzt irgendwie total verwirrt.

[Klotzkopp]

Gibt es einen bestimmten Grund, dass du das mit WinAPI machst, und nicht mit System.Net.Sockets.Socket?

[Kati82]

Ähm ja, also ich will alles mögliche über Sockets lernen.

Hintergrund ist der, dass ich ein Testprogramm schreibe. Dieses verbindet sich mit einem anderen Gerät (Server). Eigentlich gibt der Server nur das Echo zurück, mehr nicht. Jetzt hatte ich eigentlich vor, zwei Threads zu machen. In dem einen wird in einer Schleife (Nutzer gibt Schleife an) immerzu gesendet. In dem anderen wollte ich nur empfangen. Leider hat das nicht so funktioniert wie ich wollte. Habe mit select gearbeitet. Trotzdem ist mein Programm immer ab einer bestimmte Paketgröße oder einer bestimmten Anzahl von Schleifen abgestürzt. Wenn ich allerdings ein Thread::Sleep eingebaut habe, dann ging alles. Ich möchte aber keine Wartezeit einbauen, da das später evtl die Ergebnisse verfälschen könnte.

Server-seitig habe ich alles überprüft, da kommt alles an, was ankommen soll und er sendet auch alles wieder korrekt raus. Der Absturz erfolgt also aus meiner Sicht nachdem eigentlich schon alles ordnungsgemäß gesendet und empfangen wurde.

Und jetzt wollte ich eben ausprobieren, ob dieses WSAAsyncSelect eine Lösung für mein Problem wäre. Weiß aber eben noch nicht ganz wie ich das anwenden muss.

[Klotzkopp]

Wenn ich allerdings ein Thread::Sleep eingebaut habe, dann ging alles.

Das ist typisch für falsche oder fehlende Threadsynchronisierung. Gerade die WinAPI-Funktionen sind überhaupt nicht threadsicher, da musst du alles von Hand synchronisieren. Durch Sleeps kannst du höchstens kosmetische Fehlerbehandlung betreiben, d.h. man sieht nicht sofort, dass etwas schief läuft.

Kümmere dich um einen ordentliche Synchonisierung, dann brauchst du auch keine Sleeps.

[Kati82]

Ist mir auch klar, dass das mit dem Sleeps nicht gut ist. Deswegen suche ich ja schon nach einer Lösung. Wenn du sagst, ich muss mich um die Synchronisierung kümmern, dann lag ich wohl mit dem AsyncSelect vollkommen falsch? Ich will halt das Empfangen unabhängig vom Senden machen. Und ich dachte dazu wäre das AsyncSelect da.

[Kati82]

Hallo nochmal,

ich muss zwecks der Threadsynchronisierung nochmal was fragen. Im Allgemeinen heißt es doch, man soll Threads synchronisieren, wenn mehrere Threads auf einen Datenbereich zugreifen. Ich hatte jetzt angenommen, dass das in meinem Fall der Socket ist. Also hab ich mir überlegt, was passiert, wenn ich zwei Sockets mache (einen zum Senden und einen zum Empfangen). Ich hatte gedacht, dass ich dann unterschiedliche Datenbereiche benutze? Scheinbar nicht, denn da stürzt mein Programm auch ab. Was ist in meinem Fall dieser Datenbereich, wenn nicht dieser Socket? Oder liegts dann doch am Server?

Und um nochmal zu meiner ursprünglichen Frage zurückzukommen, WSAAsyncSelect ja oder nein?

Gruß Kati82

P.S.: Ich nutze eigentlich die ganz normalen WinSockets (winsock2.h). Das es unter .Net noch Sockets gibt, wusste ich anfangs nicht. Ich hab aber keine Lust das jetzt alles umzuschreiben.

[Klotzkopp]

Scheinbar nicht, denn da stürzt mein Programm auch ab.

Was heißt denn "stürzt ab". Wie lautet die Fehlermeldung? An welcher Stelle im Code passiert es?

Was ist in meinem Fall dieser Datenbereich, wenn nicht dieser Socket?

Keine Ahnung, wir wissen ja nicht, wie der Code aussieht.

Und um nochmal zu meiner ursprünglichen Frage zurückzukommen, WSAAsyncSelect ja oder nein?

Mein Auto springt nicht an. Winterreifen ja oder nein?

Die Antwort auf die Frage löst dein Problem nicht.

[Kati82]

Was heißt denn "stürzt ab". Wie lautet die Fehlermeldung? An welcher Stelle im Code passiert es?

Nachdem der Client mit Senden und empfangen fertig ist kommt diese Fehlermeldung (also nix mit Exception oder so). Es wird auch keine Zeile oder so angegeben.

NetworkTest.exe hat ein Problem festgestellt und muss beendet werden.

... und das übliche Bla Bla, ob der Problembericht gesendet werden soll.

Hab aber gerade eben herausgefunden, dass es irgendwie an der Terminierung des Empfangspuffer liegt. Da muss ich nochmal genauer nachschauen.

Mein Auto springt nicht an. Winterreifen ja oder nein?

Die Antwort auf die Frage löst dein Problem nicht.

Und solche blöden Sprüche auch nicht. Ich hab doch beschrieben, was ich machen will. Soll ich meine Frage umformulieren? Mal ganz unabhängig von meinem Code: Wenn ich das Empfangen unabhängig vom Senden machen möchte (kein Echo machen), ist es dann besser WSAAsyncSelect zu benutzen oder doch lieber select? Mit select (synchron) scheints ja zu funktionieren. Aber nachdem was ich in Büchern und Internet gelesen habe, ist wohl WSAAsyncSelect (asynchron) besser. Stimmt diese Vermutung?

Die Antwort soll auch übrigens nicht mein Problem lösen, sondern eher zu einem besseren Verständnis für Socketprogrammierung meinerseits.

[Klotzkopp]

Nachdem der Client mit Senden und empfangen fertig ist kommt diese Fehlermeldung (also nix mit Exception oder so). Es wird auch keine Zeile oder so angegeben.

Dann benutz den Debugger. Dafür ist er da.

Und solche blöden Sprüche auch nicht.

Dieser "blöde Spruch" sollte verdeutlichen, dass die Antwort auf deine Frage dich nicht weiterbringt. Die Frage, ob Winterreifen oder nicht ist sicherlich wichtig, aber sie bringt dich nicht weiter, wenn dein Auto nicht anspringt.

Mal ganz unabhängig von meinem Code: Wenn ich das Empfangen unabhängig vom Senden machen möchte (kein Echo machen), ist es dann besser WSAAsyncSelect zu benutzen oder doch lieber select?

Die Antwort auf diese Frage ist aber nicht unabhängig von deinem Code.

Mit select (synchron) scheints ja zu funktionieren. Aber nachdem was ich in Büchern und Internet gelesen habe, ist wohl WSAAsyncSelect (asynchron) besser. Stimmt diese Vermutung?

Wenn grundsätzlich eine Funktion "besser" wäre als die andere, hätte die andere keine Daseinsberechtigung. Auch hier: Sind Winterreifen oder Sommerreifen besser? Das soll kein "blöder Spruch" sein, sondern dir klarmachen, dass manche Fragen ohne Kontext nicht beantwortet werden können.

Die Antwort soll auch übrigens nicht mein Problem lösen, sondern eher zu einem besseren Verständnis für Socketprogrammierung meinerseits.

Asynchrone Funktionen und Threads sind zwei Mechanismen dafür, dass ein Programm weiterlaufen kann (z.B. auf Benutzereingaben reagieren), während es auf etwas anderes wartet.

Beides zu benutzen, klingt erst mal seltsam. Aber wie gesagt, ohne genauere Informationen über den Zweck und Aufbau deines Programms kann man das nicht beantworten.

[Kati82]

Ok, welche Reifen man nehmen benutzen sollte, hängt von der Jahreszeit ab. Und ich nahm an, dass aufgrund meiner Beschreibung, was ich machen möchte, man so eine gewisse Abhängigkeit erkennen kann. Wenn nicht, dann tuts mir leid. Ich kann halt manchmal meine Probleme nicht so richtig verständlich machen.

Ich habe jetzt meinen Client zum Laufen gebracht (siehe Anhang). Habe mal versucht nur den wesentlich Teil zu zeigen (hoffentlich habe ich nichts wichtiges weggelöscht). Wenn ich im Form den Test starte, dann springt das Programm in die Funktion SendInLoop (als neuer Thread) rein.

Wie man sieht läuft das ganze jetzt über select. Ich finde, das ganze läuft eher suboptimal. Das ne große Schleife viel Zeit frisst ist mir auch klar. Aber obwohl ich die ganze Verarbeitung in extra Threads mache, friert mein GUI ein. Obwohl es das auch schon wieder nicht ganz trifft. Es reagiert halt alles sehr stark verzögert. Auch die CPU-Last macht (verständlicherweise) einen großen Sprung nach oben - aber das wird man wohl bei ner großen Schleife nicht verhindern können. Das bringt mich zu der Annahme, das mein Programm stark verbesserungswürdig. Wenn sich also jemand mal kurz den Quellcode anschauen würde und mir etwas konstruktive Kritik oder Verbesserungsvorschläge geben kann, wäre ich sehr dankbar.

TCPclient.txt

[Klotzkopp]

Das ne große Schleife viel Zeit frisst ist mir auch klar.

Ich weiß nicht, wie du die "Größe" einer Schleife bemisst, aber das ist zunächst mal Unsinn.

Auch die CPU-Last macht (verständlicherweise) einen großen Sprung nach oben - aber das wird man wohl bei ner großen Schleife nicht verhindern können.

Schon wieder diese "große Schleife". Dass dein Programm die CPU auslastet, ist nicht verständlich. Welcher Thread erzeugt denn die hohe Last? Tritt das Problem auch auf, wenn du den Receive-Thread nicht startest?

Das hier ist zumindest ungewöhnlich:

while ((bytes < frameSize))

{

	bytes = send(client, cBuffer, frameSize, 0);

[/code]
Wenn send irgendwann einmal nicht alle Bytes auf einmal loswird, schickst du den gesamten Puffer nochmal. Normalerweise würde man nur den nicht versendeten Teil der Daten nochmals abschicken.

[Kati82]

Was ist, wenn der Nutzer 50.000 Bytes pro Schleife versenden möchte. Und dazu nochmal eine Schleifenanzahl von sagen wie mal 500. Also bei mir reicht das schon aus, dass das Programm zwei drei Minuten zu tun hat, bis es fertig ist. Wenn die Anzahl noch größer sein sollte, dann dauert das ja ewig. Ich muss noch dazu sagen, dass ich dem Nutzer die Möglichkeit geben möchte, ne Endlosschleife durchführen zu lassen. Und wenn man die nicht abbrechen kann, wäre das äußerst schlecht.

Mit der while-Schleife hast du Recht. Danke. Da war ich wohl auf dem Holzweg, weiß auch nicht mehr, warum ich das gemacht habe.

Und auch wegen dem ReceiveThread scheinst du Recht zu haben. Kann mir aber noch nicht erklären, warum das so ist. Muss ich noch näher untersuchen.

[Kati82]

Ich hab zumindest die Ursache raus, glaube ich. In dem ReceiveThread speichere ich doch das, was angekommen ist in einen String. Was ich im Anhang weggelassen habe, ist, dass ich den String per Invoke an mein Form weiterleite und dass es den String dort in eine RichTextbox anhängen soll. Das hatte ich nur gemacht, damit ich sehe, was passiert und was alles ankommt. Wenn ichs weglasse, gehts.

[Kati82]

Ich muss jetzt doch noch mal nachfragen. In dem Empfangsthread habe ich doch ein select mit Timeout eingebaut. Also wenn nach 1 Sekunde nichts empfangen wurde, dann soll er die while-Schleife verlassen. Den Timeout brauche ich deswegen, weil zwischen Start des Threads und dem Senden wohl mehr Zeit vergeht als zwischen dem Start des Threads bis zu dem select.

Diesen Timeout möchte ich gerne wegmachen, da ich die Zeit zwischen Senden und Empfang messen möchte. Wie stelle ich das jetzt am besten an?

Habe gelesen, dass es eine Funktion fork() gibt. Hab das aber immer nur in Verbindung mit Servern gelesen, aber ich mach ja einen Client. Kann man das auch für Clients anwenden? Wäre das der richtige Ansatzpunkt? Wenn ja, wär es nett wenn ihr mir ein paar Links oder so nennen könntet, wo ich das nötige Hintergrundwissen nachlesen kann, da ich noch nicht so richtig weiß, wie das ganze funktioniert und wie ich es anwenden soll.

Ansonsten bin ich auch für jeden anderen Ratschlag von euch dankbar.

Gruß Kati82

[Klotzkopp]

In dem Empfangsthread habe ich doch ein select mit Timeout eingebaut. Also wenn nach 1 Sekunde nichts empfangen wurde, dann soll er die while-Schleife verlassen. Den Timeout brauche ich deswegen, weil zwischen Start des Threads und dem Senden wohl mehr Zeit vergeht als zwischen dem Start des Threads bis zu dem select.

Aber auch nur deshalb, weil du bei Auslaufen des Timeouts den Empfang abbrichst. Das ist beim Empfangen eher unüblich.

Normalerweise hat man aber auch irgendein Protokoll in dem Bytestrom, so dass man anhand der Daten selbst erkennen kann, wann Schluss ist. Innerhalb dieses Protokolls mag es dann Zustände geben, bei denen innerhalb einer bestimmten Zeit Daten empfangen werden müssen. Aber wenn man einfach nur auf Daten wartet, ist diese Vorgehensweise merkwürdig.

Diesen Timeout möchte ich gerne wegmachen, da ich die Zeit zwischen Senden und Empfang messen möchte. Wie stelle ich das jetzt am besten an?

Was heißt denn "wegmachen"? Wenn du hier nicht select benutzt, und einfach nur recv aufrufst, wartet das eben, bis Daten da sind. Das hat mit einer Zeitmessung recht wenig zu tun.

Habe gelesen, dass es eine Funktion fork() gibt. Hab das aber immer nur in Verbindung mit Servern gelesen, aber ich mach ja einen Client. Kann man das auch für Clients anwenden?

Das ist wieder so eine Reifenfrage. Klar kann man fork in Clients anwenden. Die Frage ist, ob und wann das sinnvoll ist. fork dupliziert den aufrufenden Prozess, d.h. du hast danach 2 Clients. Was in deinem Fall totaler Blödsinn wäre.

Ansonsten bin ich auch für jeden anderen Ratschlag von euch dankbar.

Ich würde dir raten, dir ein Client/Server-Beispiel zu suchen, das auch einen Sinn hat. Einfach nur sinnlose Daten an einen Server zu senden, der dieselben Daten wieder zurückschickt, ist nicht gerade praxisrelevant, denn damit sind sowohl Client und Server als auch die Kommunikation zwischen ihnen zustandslos.

[Kati82]

Ja, das ist wirklich wie die Frage mit den Reifen. "Was brauche ich zum Reifen wechseln? Einen Hammer vielleicht?" Wenn man nicht verstehen kann, wozu was gut ist, dann wird man auch nicht wissen, ob es für seine Problemstellung geeignet ist. Deswegen habe ich nachgefragt.

Natürlich könnte ich den Timeout in der select-Anweisung weglassen. Somit hätte ich einen Thread der endlos lang empfangen würde, solange bis man den Thread abbricht. Und das mit dem Protokoll, da ist natürlich was Wahres dran. Aber dann frage ich mich, wie das die anderen Tools, die im Internet rumschwirrden, machen, die dann hinterher die Datenübertragungsrate angeben. Da sieht man ja im Wireshark das die auch nur "irgendwas" senden. Ich glaube kaum, dass die erst senden und in der gleichen Funktion dann auf die Antwort warten. Oder vielleicht doch???

Das heißt jedenfalls für mich, dass ich mir Gedanken drüber mache werde, wie ich das Ganze besser lösen kann.

Aber danke für die Hinweise.

[Klotzkopp]

Aber dann frage ich mich, wie das die anderen Tools, die im Internet rumschwirrden, machen, die dann hinterher die Datenübertragungsrate angeben.

Indem sie die bisher übertragene Datenmenge durch die verstrichene Zeit teilen. Datenübertragungsraten sind immer Durchschnittswerte über bestimmte Zeitspannen. Das hat nichts damit zu tun, wie deine Empfangsfunktion aussieht.

Da sieht man ja im Wireshark das die auch nur "irgendwas" senden.

Wer sind denn "die"? Nur weil das Protokoll nicht sofort offensichtlich ist, heißt das nicht, dass da "irgendwas" gesendet wird.

Ich glaube kaum, dass die erst senden und in der gleichen Funktion dann auf die Antwort warten. Oder vielleicht doch???

Es gibt nicht die einzig wahre Art und Weise, einen Netzwerkclient zu implementieren. Es kommt auf das Protokoll an. Üblicherweise trennt man die Datenübertragung von der Verarbeitung, und implementiert einen endlichen Automaten.

Solange nicht klar ist, was du eigentlich machen willst, ist es nicht sinnvoll, sich darüber Gedanken zu machen, wie du es machst.

[Kati82]

Ok, ich weiß, ich nerve.

Als Beispielprogramm, wo ich aus meiner Laiensicht zumindest kein Protokoll erkennen kann, wäre NetIO. Aber dass nur so nebenbei.

Ich weiß übrigens, was ich machen will. Wenn ich mich an irgendeiner Stelle nicht verständlich ausdrücke, dann musst du mir auch schon sagen wo. Sonst weiß ich nicht, was ich noch mal beschreiben sollte.

Mit dem Timeout hast du mich überzeugt. Den habe ich weggelassen, damit der Empfang nicht abgebrochen wird. Empfang wird also nur beendet, wenn ich an einer anderen Stelle sage, dass der Empfangsthread abgebrochen werden soll. Dafür habe ich jetzt nen Timer eingebaut, der nachfragt, wieviele Bytes versendet worden sind. Daraus kann ich dann die Datenrate berechnen. Und das funktioniert auch halbwegs.

Eigentlich traue ich mich schon gar nicht mehr ne Frage zu stellen.

Du sagst, dass die Übertragungsraten meist Durschnittswerte über eine bestimmte Zeitspanne sind. Jetzt ist mir aber bei meinem Programm was aufgefallen. Der Befehl send() ist ja bei mir blockierend. Was ist, wenn ich jetzt ein sehr großes Frame senden möchte, dessen Übertragung mehrere Sekunden dauert. Wenn ich jetzt allerdings mittels meines Timers die Datenrate berechne, dann kommt als Ergebnis raus, dass ich in der ersten Sekunde dieses wahnsinnig große Frame gesendet, aber in den darauffolgenden Sekunden überhaupt nichts sende (wegen blockierender Socket in der while-Schleife). Diese Angabe entsprechen nicht der Realität, denn das Frame wird in mehrere kleine aufgeteilt und dann gesendet. Wie bekomme ich also jetzt den tatsächlichen Wert (den Durchschnittswert) heraus? Ist das machbar? Die Zeit zu messen, macht in diesem Fall ja auch keinen Sinn. Ich hätte nämlich schon gerne, dass nach einer vergangenen Sekunde ein realer Wert da steht.

Hoffentlich habe ich mich diesmal verständlich ausgedrückt.

[Klotzkopp]

Als Beispielprogramm, wo ich aus meiner Laiensicht zumindest kein Protokoll erkennen kann, wäre NetIO.

Ein Programm, das zur Messung der Übertragungsgeschwindigkeit dient, ist so ziemlich der einzige Anwendungsfall, wo der eigentliche Inhalt der Daten egal ist.

Ich weiß übrigens, was ich machen will. Wenn ich mich an irgendeiner Stelle nicht verständlich ausdrücke, dann musst du mir auch schon sagen wo. Sonst weiß ich nicht, was ich noch mal beschreiben sollte.

Es geht darum, dass dein Programm keinen Sinn hat, wenn man mal von der Geschwindigkeitsmessung absieht. Die Datenübertragung erfüllt keinen Zweck, also ist es auch sinnlos, sich über die richtige Verarbeitung dieser Daten Gedanken zu machen.

Diese Angabe entsprechen nicht der Realität, denn das Frame wird in mehrere kleine aufgeteilt und dann gesendet.

Das hast du aber nicht gemessen. Du hast nur gemessen, was send tut: Die Daten beim Betriebsystem abliefern.

Wie bekomme ich also jetzt den tatsächlichen Wert (den Durchschnittswert) heraus?

Es gibt keinen "tatsächlichen" oder "realen" Wert. Es gibt nur Durchschnittswerte, und die hängen davon ab, auf welcher Ebene und mit welchem Intervall du misst.

Ist das machbar? Die Zeit zu messen, macht in diesem Fall ja auch keinen Sinn. Ich hätte nämlich schon gerne, dass nach einer vergangenen Sekunde ein realer Wert da steht.

Wie gesagt, "reale" Werte gibt's sowieso nicht, weil die Daten nicht kontinuierlich übertragen werden. Wenn du die Werte "schönrechnen" möchtest, mach das Messintervall größer.

[Kati82]

Jetzt hör mal auf mich als dumm hinzustellen oder mein Programm als sinnlos zu erklären. Ich sags nochmal, das soll ein Testprogramm werden. Zum einen soll die Geschwindigkeit gemessen werden und zum anderen soll später, allerdings nicht auf TCP basierend sondern über ein anderes Protokoll, der Server mit Verarbeitungsbefehlen bombardiert werden. Aber bis dahin ist es noch ein weiter Weg. Es kann nicht jeder so ein Experte sein wie du. Ich will nämlich erst mal verstehen, was ich eigentlich mache.

[Klotzkopp]

Jetzt hör mal auf mich als dumm hinzustellen oder mein Programm als sinnlos zu erklären.

Ich habe dich nicht als dumm hingestellt. Ich habe versucht, dir zu erklären, warum deine Herangehensweise nicht zielführend ist. Wenn du das nicht möchtest, lass ich es eben.

zum anderen soll später, allerdings nicht auf TCP basierend sondern über ein anderes Protokoll, der Server mit Verarbeitungsbefehlen bombardiert werden.

Das ist das erst Mal, dass du mit solchen Informationen rausrückst. Wenn dieses "andere Protokoll" nicht gerade auf UDP basiert, wirst du mit Sockets sowieso nicht viel erreichen können.

Wenn es UDP-basiert ist, versuchst du dir gerade Wissen zu Stream-Sockets anzueignen, obwohl du hinterher Datagram-Sockets benutzen musst.

Du kannst aus einem Programm, das Problem A löst, nicht sonderlich viel darüber lernen, wie man Problem B löst.

Aber bis dahin ist es noch ein weiter Weg. Es kann nicht jeder so ein Experte sein wie du.

In so manchem Fall liegt das an Beratungsresistenz oder ausgeprägter Dünnhäutigkeit.

Ich will nämlich erst mal verstehen, was ich eigentlich mache.

Du machst aber doch noch gar nichts.

Du kannst dir jetzt natürlich lang und breit darüber Gedanken machen, wie du Daten am besten verarbeitest, die gar nicht verarbeitet werden müssen, weil es sich um einen reinen Geschwindigkeit- oder Lasttest handelt. Erwarte aber bitte nicht, dass du dabei etwas lernst, das du auf ein Protokoll mit echtem Kontext übertragen könntest.

[Kati82]

Hallo nochmal,

bitte versteh mich nicht falsch, ich bin für jeden Ratschlag dankbar. Beratungsresistent bin ich ganz und gar nicht. Versteh nur halt manchmal nicht, was du meinst.

Nochmal zur Verdeutlichung. Das Testprogamm besteht eigentlich aus 3 verschiedenen Tests. Beim ersten wird der Ping getestet. Das funktioniert soweit. Der zweite Test läuft eben über TCP und soll die Geschwindigkeit bzw. den Datendurchsatz bestimmen. Der dritte Test geht über das S7-Protokoll. Da weiß ich allerdings noch nicht, wie ich das mache, habe mir allerdings bis jetzt auch noch keine Gedanken drüber gemacht. Muss da noch ein paar mehr Informationen einholen.

Ich habe mir allerdings noch einige Überlegungen wegen dem Datendurchsatz beim Senden gemacht. Mir ist da so ne Idee gekommen, ohne dass man "Schönrechnen" muss. Muss aber noch ausprobieren, ob das klappt. Was ist, wenn ich mir einen zweiten Socket erstelle und diesen an meine Adresse vom Rechner binde. Rein theoretisch müsste ich doch dann mitkriegen, was alles über die IP vom Rechner läuft. Könnte das funktionieren?

[Kati82]

Ok, ich muss meine Idee wieder verwerfen. Das bind mit meiner Rechner-IP funktioniert nicht, da diese Adresse bereits von dem anderen Socket in Benutzung ist.