boost::asio::local::stream_protocol

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
alexander_ro
Beiträge: 298
Registriert: 16.01.2006 17:44:21
Lizenz eigener Beiträge: GNU General Public License

boost::asio::local::stream_protocol

Beitrag von alexander_ro » 20.09.2010 19:16:41

Hallo Mädels und Jungs,

irgendwie dachte ich der Boost Netzwerk iostream für einen Domainsocket funktioniert so wie die von der STL für Files aber leider tun die das bei mir nicht. Wenn ich gesendete Daten dann im Client mit

Code: Alles auswählen

netStream >> strDaten;
zu lesen versuche blockiert der Aufruf. Das tut er nur nicht wenn in den Daten ein Leerzeichen enthalten ist. Dann werden die Daten bis zum Leerzeichen gelesen und kein Byte weiter.

Es gibt zwar die möglichkeit mit getline Zeilenweise aus dem Stream zu lesen aber woher soll der Client wissen wie viele Zeilen es gibt. Versucht man einmal zu oft aus dem Stream zu lesen blockiert das ganze. Ich habe aber trotz dem langen Suchen nicht gefunden wie ich im Clientprogramm feststellen kann wie viele Daten ich lesen kann ohne das das blockiert und eigentlich würde ich sagen man braucht keine Streams wenn ich mich dann um den Mist selber kümmern muß. Dann kann ich gleich die BSD-Socketfunktionen benutzen die arbeiten wenigstens sauber und so wie man es erwarten würde.

Kann mir vielleicht jemand sagen wie die Asiomacher sich das vorstellten?
Wenn jemand was anderes an C++ Netzwerkklassen kennt die Praxisnäher zu benutzen sind wäre mir auch sehr geholfen?
Momentan scheinen mir Netzwerktechnisch die Socket C-Funktionen das einzig brauchbare.

Viele Grüße
Alexander

Benutzeravatar
schorsch_76
Beiträge: 2611
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: boost::asio::local::stream_protocol

Beitrag von schorsch_76 » 20.09.2010 22:00:15

Hi,

zu boost::asio kann ich dir nur wenig sagen, ausser das meine HTTP Clients funkionieren ;)

Bei Fragen zu boost::asio wende dich doch an die boost user Mailing Liste Dort stehen dir die Entwickler dieser Bibliothek zu Verfügung, welche das Ding in und auswendig kennen ;)

.. oder der Boost IRC Channel
#boost IRC channel

In addition to the mailing lists presented above, a #boost IRC channel on freenode is frequented by some boost users. As usual with IRC channels, one should not necessarily expect that his questions will be answered. The channel is not moderated.
Gruß

schorsch

[1] http://www.boost.org/community/groups.html#users

alexander_ro
Beiträge: 298
Registriert: 16.01.2006 17:44:21
Lizenz eigener Beiträge: GNU General Public License

Re: boost::asio::local::stream_protocol

Beitrag von alexander_ro » 21.09.2010 10:30:12

Danke für die Info. Ich dachte vielleicht hat jemand hier schon mal eine Lösung dafür gefunden aber scheinbar wird boost::asio nicht so viel benutzt.

Benutzen Deine HTTP-Clients auch die streams?

Grüße
Alexander

Benutzeravatar
schorsch_76
Beiträge: 2611
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: boost::asio::local::stream_protocol

Beitrag von schorsch_76 » 21.09.2010 11:38:39

Hi,

meine HTTP Clients sind eigfentlich genauso wie die Beispiele [1] [2] aufgebaut. Je nach Anforderung eben Asyncron oder Syncron. Wenn die Verbindung abgebaut wurde, pack ich die Daten und verarbeite sie. Ansonsten wird einfach alles an einen std::string angehängt wenn neue Daten eintreffen.

Anmerkung zu deinem Problem:
Wenn du über die Streams deine Daten schicken willst musst du das Protokoll das du benutzt anpassen. Bsp. Zuerst die Anzahl der Bytes die gesendet werden müssen rüberschieben und hinterher dann die Daten. So weis der Client wieviele Daten er per getline rausziehen muss.
Schau dir hierzu das Chat Beispiel Server [3] / Client [4] / Message [5] an. Da gibt es einen Header welcher die Informationen (Datenlänge) enthält und den Body welcher die Daten enthält.

Mit dem C-Sockets musst du auch auf dem TCP Socket ein zusätzliches Protokoll etablieren damit du weist wieviele Daten jetzt empfangen werden müssen.

Bsp.:
HTTP-Protokoll
|
TCP - Socket
|
Netzwerkstack
|
...

Du musst hier eben das HTTP Protokoll durch dein Protokoll ersetzen ;)

Viel Erfolg

Schorsch

EDIT: Eventuell ist auch Serialization über Boost::sockets was für dich [6]. Hier wird ein "std::vector<stock> stocks_" serialisiert und über einen Socket an den Client übermittelt. Die Klasse "stock" ist eben serializable. Die Boost Serialisierung setze ich sehr sehr oft ein um Konfig Daten im XML Format auf Festplatte zu schreiben und um sie zu lesen.

[1] Asyncron: http://www.boost.org/doc/libs/1_44_0/do ... client.cpp
[2] Syncron: http://www.boost.org/doc/libs/1_44_0/do ... client.cpp
[3] http://www.boost.org/doc/libs/1_44_0/do ... server.cpp
[4] http://www.boost.org/doc/libs/1_44_0/do ... client.cpp
[5] http://www.boost.org/doc/libs/1_44_0/do ... essage.hpp
[6] http://www.boost.org/doc/libs/1_44_0/do ... ialization

Benutzeravatar
bmario
Beiträge: 1257
Registriert: 05.09.2007 12:15:47
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dresden

Re: boost::asio::local::stream_protocol

Beitrag von bmario » 21.09.2010 12:24:03

Hi,
ich hab mich auch mit Boost::Asio rumgequält, aber eigentlich läuzft es ganz gut. Nur brauchst du unbedingt, wie Schorsch schon sagte ein Layer 4-7 Protokoll, das du dann implementierst. Hier z.B. ein Protokoll das Nachrichten mit einem Newline abschließt:

NoPaste-Eintrag34971

Hoffe das hilft dir.

*edit hubs, da fehlte was im Namen :oops:
Zuletzt geändert von bmario am 21.09.2010 12:52:03, insgesamt 1-mal geändert.
Nichts zu tun ist viel besser,
als mit viel Mühe nichts zu schaffen. - Laotse

Benutzeravatar
schorsch_76
Beiträge: 2611
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: boost::asio::local::stream_protocol

Beitrag von schorsch_76 » 21.09.2010 12:50:02

Ach ja: Hier [1] noch ein Online Buch zu Boost, das mir sehr geholfen hat.

Zu den Socket C Funktionen kann ich dir sagen, dass es anfangs sehr einfach erscheint, aber du auch hier nicht garantieren kannst, dass alle daten mit einem recv() gelesen werden. Hier musst du auch wieder erst zwischenpuffern, aneinanderhängen und dann wieder mit deinem Protokoll drüber um das ganze auseinanderzufummeln. Hab ich bei meinem ersten Netzwerkprojekt gemacht. War nicht lustig ;)

Gruß

schorsch

[1] http://www.highscore.de/cpp/boost/

alexander_ro
Beiträge: 298
Registriert: 16.01.2006 17:44:21
Lizenz eigener Beiträge: GNU General Public License

Re: boost::asio::local::stream_protocol

Beitrag von alexander_ro » 21.09.2010 13:56:56

Danke für die vielen Infos. Ist schon eine weile her das ich die C-Socketfunktionen benützt habe und meine mich zu errinnern das es eine Funktion gab mit der man feststellen konnte wie viele Daten man noch lesen kann ohne das die Funktion blockiert. Aber möglich das ich mich täusche.

Bei den Streams dachte ich halt die sorgen selbst dafür wie bei Dateien mit dem EOF mir mitzuteilen das ich alle Daten erhalten habe die gesendet wurden. Wäre ja theoretisch möglich das tut die Asio Implemetierung aber nicht. Muß man wirklich selber machen. Hm, anscheinend erwarte ich immer ein bisschen zuviel.

Wenn ich es richtig sehe liest man am besten immer Zeilen und hängt in jedem Fall am Ende ein Newline an. Damit der Client weiss wie viel er lesen kann könnte man wie im HTTP einen Header mit content-lenght: xyz senden und die Header wie beim HTTP mit einer Leerzeile vom Content trennen. Dann muß der Client die Zeilenlängen nur zusammenzählen damit er weiss wie viele Bytes des Contents noch zu lesen sind.

Grüße
Alexander

Benutzeravatar
bmario
Beiträge: 1257
Registriert: 05.09.2007 12:15:47
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dresden

Re: boost::asio::local::stream_protocol

Beitrag von bmario » 21.09.2010 14:11:06

Richtig, Boost::asio ist halt nur TCP/IP (oder UDP/IP). Ein EOF ist dahingehend sinnlos, da es bedeuten würde, dass die Verbindung abgeschlossen ist und somit beendet werden kann, was ja aber nicht im Sinne des Erfinder (oder eher des Programmierers) ist :)

Das einfachstes wäre es:

a) ein vorhandenes Protokoll zu nutzen, etwa HTTP und den Content XML basiert übertragen
b) ein eigenes Protokoll zu nutzen, dass zu jedem Zustand immer wenige, am besten nur einen nächsten Zustand hat.

Mario
Nichts zu tun ist viel besser,
als mit viel Mühe nichts zu schaffen. - Laotse

Benutzeravatar
schorsch_76
Beiträge: 2611
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: boost::asio::local::stream_protocol

Beitrag von schorsch_76 » 21.09.2010 16:13:55

Hier hab ich noch für dich ein (sehr) einfachen aber ausbaubaren Protokollparser auf Basis von Boost::state_chart.

NoPaste-Eintrag34975

Gruß

schorsch

alexander_ro
Beiträge: 298
Registriert: 16.01.2006 17:44:21
Lizenz eigener Beiträge: GNU General Public License

Re: boost::asio::local::stream_protocol

Beitrag von alexander_ro » 21.09.2010 21:32:16

Also die Streams für Netzkommunikation bieten nicht wirklich einen Mehrwert. Sind eher etwas wirr. Aber wenn man mit allen anderen Netzwerkprogrammen die evtl. ja in anderen Sprachen geschrieben sind kommunizieren können möchte dann gehts auch nicht anders (da hatte ich bisher nicht dran gedacht). Wenn die bei den read und write Methoden bleiben würden und die Streams in die Tonne hauen wäre die Library leichter verständlich. Zumindest meine Meinung.

Also mit dem HTTP content-length könnte ich micht noch anfreunden aber meine Abneigung gegen XML ist fast so groß wie die gegen einen nicht unbekannten großen Software Hersteller. :wink:
Ich muß nur die Daten die ein Programm vom Apache erhält an ein anderes weiterreichen und dort werden dann die Daten verarbeitet und das Ergebnis wieder zum Client gesendet. Bei der nächsten Anfrage des Clients wird dann wieder eine Verbindung zu diesem Prozess aufgebaut und weil er noch läuft stehen alle DB-Cursor und berechneten Daten noch zur Verfügung. Bisher machte ich das mit SharedMem aber in Zukunft soll es möglich sein das solche Prozesse auf verschiedenen Servern laufen können und deshalb der Umbau. Erst mal nur über Domainsockets und später auch über TCP. Das wäre dann ja nicht mehr schwer.

Dabei fällt mir noch eine Frage ein.

Code: Alles auswählen

acceptor.accept(*netStream.rdbuf());
Kann man so einen Acceptor dazu überreden wenn nach einer bestimmten Zeit keine Verbindung aufgebaut wird sich zu beenden?
Irgendwie habe ich so den verdacht das das nicht geht.

... und danke für die schönen Beispiele (haben mir sehr geholfen) das letzte vom Schorsch muß ich mir noch in Ruhe ansehen.

Grüße
Alexander

Benutzeravatar
schorsch_76
Beiträge: 2611
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: boost::asio::local::stream_protocol

Beitrag von schorsch_76 » 22.09.2010 08:17:55

Hi!

Na du machst dir einen Timer der nach deiner Zeit ein

Code: Alles auswählen

acceptor.cancel();
acceptor.close();
aufruft.

Siehe [1] [2]


Gruß

schorsch

[1] http://www.boost.org/doc/libs/1_44_0/do ... eptor.html
[2] http://www.boost.org/doc/libs/1_44_0/do ... s.timeouts

alexander_ro
Beiträge: 298
Registriert: 16.01.2006 17:44:21
Lizenz eigener Beiträge: GNU General Public License

Re: boost::asio::local::stream_protocol

Beitrag von alexander_ro » 22.09.2010 15:42:05

Irgendwie habe ich das cancel/close bei acceptor überlesen. Das beim Stream hatte ich gefunden ist schon mal praktisch wenns das gibt.

Das Daten hin und her schieben geht schon gut. Was mir noch Probleme bereitet ist das beenden der Verbindung ohne das Daten verschwinden. Wenn der Serverprozess die Daten losschickt und gleich die Verbindung mit netStream.close (); schließt kann der Client sie nicht mehr lesen. Wenn man jetzt den Client eine Bestätigung senden lässt das er alle Daten erhalten hat woher weiss dann der Client das die Bestätigung beim Server angekommen ist.

Irgendwie so ein Hühnchen Ei Problem wie es scheint.

Sicher geht das eigentlich nur wenn beide einen Close-Wunsch senden und warten bis der da ist (und hofft nirgends gehen Daten verloren). Dann hat jeder Prozess die Sicherheit das der jeweils andere sein OK zum beenden der Verbindung gegeben hat.
[Edit] Nee geht so auch nicht ist unfug ...[/Edit]

Grüße
Alexander

Benutzeravatar
bmario
Beiträge: 1257
Registriert: 05.09.2007 12:15:47
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dresden

Re: boost::asio::local::stream_protocol

Beitrag von bmario » 22.09.2010 16:51:15

Also das das schließen funktioniert, darum kümmert sich normal TCP. Ich denke du hast dir da eher ein Timingproblem gebaut.

Du kannst entweder die Verbindung mit so einem Timer verzögert schließen, oder du musst da generell einen anderen Ansatz nutzen.
Ohne Sourcecode kann man da aber nur Kristallkugelraten machen ;)
Nichts zu tun ist viel besser,
als mit viel Mühe nichts zu schaffen. - Laotse

alexander_ro
Beiträge: 298
Registriert: 16.01.2006 17:44:21
Lizenz eigener Beiträge: GNU General Public License

Re: boost::asio::local::stream_protocol

Beitrag von alexander_ro » 22.09.2010 17:08:52

Was wird denn über einen Domainsocket benutzt? Ist das TCP ...

Wenn ich den close auskommentiere funktioniert es. Nur das dann halt der erneute Aufruf des acceptors nicht geht weil ja die Verbindung noch offen ist.

Das mit dem Timeout ist eigentlich das was ich vermeiden will. Weil die bei hoher Systemlast immer zu kurz sind und bei niedriger immer zu lange. Das macht die Anwendung instabil und langsam.

Der Sourcecode ist recht umfangreich ich schau mal wie ich das als Beispiel am besten zusammenbaue. Braucht man ja leider Client und Server zu testen.

[Edit] Noch kein fertiges Beispiel aber vielleicht hilft es sich das vorzustellen.
Server:

Code: Alles auswählen

  boost::asio::io_service io_service;
  boost::asio::local::stream_protocol::endpoint ep ("Socketfiles/" + strProzessId);
  boost::asio::local::stream_protocol::iostream netStream;
    
  netStream << strDaten;
  netStream.close ();
Client:

Code: Alles auswählen

  boost::asio::io_service io_service;
  boost::asio::local::stream_protocol::endpoint ep ("Socketfiles/" + strProzessId);
  boost::asio::local::stream_protocol::iostream netStream;
    
  std::getline(netStream, strCgiDaten);
Schließt der Server die Verbindung kann der Client die Daten nicht mehr lesen. strCgiDaten ist dann einfach leer also (strCgiDaten == "").
[/Edit]

Grüße
Alexander

Benutzeravatar
schorsch_76
Beiträge: 2611
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: boost::asio::local::stream_protocol

Beitrag von schorsch_76 » 22.09.2010 19:28:15

Na dann lass doch den Server die Daten schicken wenn der Client die Daten hat (siehe content-length header) schliest er den Socket. das bekommt der Server auch wieder mit (zumindest bei TCP).

Gruß

schorsch

alexander_ro
Beiträge: 298
Registriert: 16.01.2006 17:44:21
Lizenz eigener Beiträge: GNU General Public License

Re: boost::asio::local::stream_protocol

Beitrag von alexander_ro » 23.09.2010 00:31:54

Das geht auch nicht. Ich weiss nicht wie der Server das mitbekommen soll. Jedenfalls die Verbindung wird vom Server nicht automatisch geschlossen wenn der Client einen close macht. Damit schlägt dann ein erneuter Verbindungsaufbau fehlt weil der acceptor sich mit Fehler vom Dienst verabschiedet. Man kann den Fehler ignorieren die Frage ist nur was man dann bei jedem Aufruf an Ressorcen verliert das hab ich nicht getestet.

Ich hab mal ein bisschen in dem Asio Code gegraben. Aber das ist ein wust von bedingter Compilierung und Code Generierung mit Makros (glaube das macht seit 20 Jahren keiner mehr weil verschärft undurchsichtig). Das Projekt schweigt sich ja auch aus über Archtektur oder was die hohen Herren sich dabei dachten und sonst verwendet es wohl kaum einer nur so kann ich mir erklären warum Infos im Internet so dünn gesät sind. Der Linux Kernel und viele andere Anwendungen konnte schon vor 20 und mehr Jahren für Diagnosezwecke Statusmeldungen ausgeben. Gibts bei denen aber auch nicht. Aber C++ und Netzwerk findet man für Linux nicht besonders viel für Asio gibts ausser deren eigen Sachen nichts und da ist leider kein Beispiel dabei das so geht wie ich es bräuchte. Das dortige Beispiel mit einer Zeile vom Server zu Client senden funktioniert sogar bei mir keine Frage.

In TR2 wollen die ja Netzwerk Sachen für C++ Standardisieren ich hoffe (vermutlich vergeblich) das die die Finger von Asio lassen. Oder zumindest es nochmal Gründlich renoviern und die Archtektur mal überdenken.

Jetzt den Sourcecode durchpflügen bis ich weiss was die bei Asio unter iostream verstehen ist mir glaube ich die Sache nicht Wert. Ich glaub ich Bau das um auf die C-Socket Funktionen die sind nicht so verbugt. Gibts halt auch schon ein paar Jahrzehnte länger als Asio.

Grüße
Alexander

Benutzeravatar
schorsch_76
Beiträge: 2611
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: boost::asio::local::stream_protocol

Beitrag von schorsch_76 » 23.09.2010 07:05:06

Ich würde bevor ich das mit C-Sockets mache, nochmal mit der boost users Mailing Liste probieren. Die haben auch mir schon echt geholfen ;) Die Jungs sind hilfsbereit und wissen wovon sie reden.

Gruß

schorsch

alexander_ro
Beiträge: 298
Registriert: 16.01.2006 17:44:21
Lizenz eigener Beiträge: GNU General Public License

Re: boost::asio::local::stream_protocol

Beitrag von alexander_ro » 23.09.2010 14:41:08

Ach die verstehen mich ja wieder nicht (nicht so gut mein Englisch) und da die Software meine eigene ist hab ich ja die freie Auswahl was ich verwende sonst würde ich das schon versuchen. Dank git könnte ich ja auch leicht wieder zurückwechseln wenn ich noch über eine Lösung falle ;).

Ich hab mal den Client umgebaut und was lustiges festgestellt.
So mach ich das jetzt mit dem lesen mit den C-Sockets:
[Edit]Vorher muß man den iSocket natürlich erzeugen (hab ich wegen der übersicht weg gelassen).[/Edit]

Code: Alles auswählen

  //*****
  //* Lese die neue Seite vom Subsystem.
    std::string strNeueSeite = "";

    int iSize           = 0;
    int iLength         = 0;
    int iContentLength  = 0;
    int boolHeaderLesen = true;
    char szBuffer[100];

    for (;;)
    {
      iSize = recv (iSocket, &szBuffer, sizeof (szBuffer) - 1, 0);

      if (iSize == 0)
      {
        if (iContentLength == iLength)
          break;
        else
        {
          syslog (LOG_INFO, 
                      "HtsCgiLogin->main: nicht alle Daten des Subs. gelesen, erwartet: '%d', gelesen: '%d'.", 
                      iContentLength, 
                      iLength);
          exit (1);
        }
      }
      else
      if (iSize > 0)
      {
      // Die gelesenen Date zu einem String zusammenbauen.
        szBuffer[iSize] = '\0';
        strNeueSeite = strNeueSeite + szBuffer;
        iLength = iLength + iSize;

      // Prüfe ob alle Header gelesen wurden.
        if (boolHeaderLesen)
        {
          int iPos = strNeueSeite.find ("\n\n", 0);

          if (iPos != std::string::npos)
          {
          // Den content-length Header suchen und den Wert ausschneiden und einen int daraus machen.
            std::string strHeaderName = "content-length:";

            int iPosA = strNeueSeite.find (strHeaderName, 0);
            int iPosB = strNeueSeite.find ("\n", iPosA);
            iPosA = iPosA + strHeaderName.size ();

            std::string strContentLength = strNeueSeite.substr (iPosA, iPosB - iPosA);

            std::stringstream StringToInt (strContentLength);
            StringToInt >> iContentLength;

          // Zum Prüfen der Content länge die Header länge von den gelesenen Daten abziehen.
            iLength = iLength - (iPos + 3);

          // Header aus den gelesenen Daten entfernen.
          // +2 um die zwei Newline der Trennung Header/Content mit zu entfernen.
            strNeueSeite.erase (0, iPos + 2);
          }
        }
      }
      else
      if (iSize == -1)
      {
        syslog (LOG_INFO, "HtsCgiLogin->main: Fehler beim lesen der neuen Seite.");
        exit (1);
      }
    }

    syslog (LOG_INFO, "strNeueSeite: '%s'", strNeueSeite.c_str ());
  //*
  //*****
Muß ja gehen Server mit Asio und Client mit C-Sockets - geht auch. Interessanterweise geht das jetzt. Die C-Sockets stört es nicht im geringsten das der Server die Verbindung beendet. Der Client kann die gesendeten Daten trotzdem noch lesen. Ich habe in einem Fachbuch jetzt auch gefunden das die Domainsockets sich so wie TCP verhalten. Also wird die Asio irgendwo mitbekommen das die Verbindung geschlossen wurde und gibt dem lesenden Client nur noch leer zurück. Ich weiss nicht ob die es so wollen oder ob es falsch ist oder sich das irgendwo einstellen lässt hab ich noch nicht herausbekommen.

Grüße
Alexander

Benutzeravatar
schorsch_76
Beiträge: 2611
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: boost::asio::local::stream_protocol

Beitrag von schorsch_76 » 23.09.2010 22:26:13

Hi alexander_ro,

hab grad bischen über boost:.asio gelesen da das bei mir wohl in relativ naher Zukuft auch ansteht.

Boost::asio/Asio wird dochh recht häufig eingesetzt [1]

Gruß und Viel Erfolg mit deinem Projekt

schorsch

[1] http://think-async.com/Asio/WhoIsUsingAsio

alexander_ro
Beiträge: 298
Registriert: 16.01.2006 17:44:21
Lizenz eigener Beiträge: GNU General Public License

Re: boost::asio::local::stream_protocol

Beitrag von alexander_ro » 25.09.2010 13:07:55

Hi schorsch_76,

danke für Deine Hilfe und natürlich auch für die Hilfe aller anderen.

Ich lasse das jetzt mal so: also Server mit Asio und Client mit den C-Socketfunktionen. Wenn ich das Problem noch finde Meld ich mich nochmal hier.

Grüße und auch Dir viel Erfolg mit deinen Projekten
Alexander

Antworten