Ich schreibe eine kleine verteilte Anwendung, aber ich habe ein kleines Problem, dass folgende Fehlermeldung unregelmässig vorkommt:

Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte

Ich habe da einen kleinen Server, welcher auf Clients wartet.

boost::asio::io_service server_io_service;
boost::ptr_list< tcp::socket > connections;
boost::mutex m;
...
void accepting ()
{
 for (;;)
 {
   tcp::acceptor acceptor (server_io_service, tcp::endpoint (tcp::v4(), 13) );

   tcp::socket* socket = new tcp::socket ( server_io_service );
   acceptor.accept ( *socket );
   {
     boost::lock_guard<boost::mutex> lock ( m );
     connections.push_back ( socket );
   }
 }
}

Das läuft in einem eigenen Thread ab.

Nun verbindet sich ein Client auf den gewünschten Computer und Port. Das klappt beim ersten mal bis jetzt immer. Wenn jetzt aber mehr Clients dazu kommen, bekomme ich manchmal bei 2,3 und bis jetzt spätestens bei 4 Clients den oben genannten Fehler. Ich habe das jetzt meist auf einem PC getestet (und mehrere Clients gestartet), aber ebenfalls auf einem speraten PC als Client und ich bekomme das gleiche Fehelerbild.

An einer Firewall kann es nicht liegen, da es ja beim ersten mal bis jetzt immer funktioniert hat und die Warnung von Windows ("Nicht mehr blocken") habe ich ebenfalls korrekt beim ersten mal erhalten.

Was mich am meisten verwirrt ist, dass es so unregelmässig ist (ansonsten könnte es ja eine natürliche Limitierung sein). Ich habe es mal geschafft, 3 Clients am gleichen Computer zu halten, während andere male lediglich einer ging.

Hat jemand das Problem auch mal gehabt oder weiss, an was das es liegt?

Hat jemand das Problem auch mal gehabt oder weiss, an was das es liegt?

Ich schätze mal, Dein Thread ist nicht in der Lage, die Verbindungsanforderungen schnell genug zu bearbeiten. Die Unregelmäßgkeiten kommen vermutlich von OS-Scheduler und der OS-Auslastung.
Wieso benutzt Du keine asynchronen Operationen? Das ist viel einfacher, und funktioniert bei mir selbst dann, wenn 20 Clients gleichzeitig versuchen, sich zu verbinden.

PS: Was passiert denn noch so alles, nachdem Du den socket an die Liste übergeben hast? Ist nach dem push_back wirklich schluss?

Jap. Danach ist Schluss. Sprich die Schleife geht wieder nach oben und wartet auf einen neuen. (Ich habe da noch 2 Konsolenausgaben drin, aber die tun ja nix zur Sache, habe es auch mal ohne die probiert und gab das gleiche Ergebnis).

Wenn es denn wirklich an dem synchron/asynchron liegt, dann werde ich das umstellen, aber meiner Meinung nach müsste das ja auch synchron gehen.. (gleichzeitg habe ich noch nie connected, also liegts nicht daran, dass es da einen gleichzeitigen Zugriff gibt).

Hmm. Ich dachte, dass es ja auch synchron gehen müsste. Wäre aber schon auch geplant das dann auf asynchrone Zugriffe einzustellen.
Warum schnell genug? - Der sollte ja auch einfach warten..

Um ehrlich zu sein: Ich hätte auch erwartet das es geht. Aber es sieht wohl so aus, als wenn accept nicht nachkommt.

drakon schrieb:

Oder hat es da intern irgendwo einen Timeout? -

Wenn ich ich recht entsinne, dass muss zu einem TCP Connect auf der Gegenstelle ein aktiver Acceptor sein. Sonst gibt es beim connecten einen Fehler.

drakon schrieb:

Jap. Danach ist Schluss. Sprich die Schleife geht wieder nach oben und wartet auf einen neuen.

Hmm, es passiert also quasi gar nichts. Dann ist es umso merkwürdiger, dass es zeitlich anscheinend nicht rumkommt. In welchem zeitlichen Abstand versuchen sie die Clients denn, sich zu verbinden?

drakon schrieb:

Oder hat es da intern irgendwo einen Timeout? -

Wenn ich ich recht entsinne, dass muss zu einem TCP Connect auf der Gegenstelle ein aktiver Acceptor sein. Sonst gibt es beim connecten einen Fehler.

Den gibt es ja eigentlich immer, da ja in der Schleife gleich wieder nach oben gegangen wird und ein neuer (mittlerweilen ist es der gleiche) wieder wartet.

drakon schrieb:

Jap. Danach ist Schluss. Sprich die Schleife geht wieder nach oben und wartet auf einen neuen.

Hmm, es passiert also quasi gar nichts. Dann ist es umso merkwürdiger, dass es zeitlich anscheinend nicht rumkommt. In welchem zeitlichen Abstand versuchen sie die Clients denn, sich zu verbinden?

Hmm. Ich warte ein paar Sekunden. (Dafür ist dann ja auch die Ausgabe da, sprich ich gebe bevor ich acceptor.accept() aufrufe etwas auf der Konsole aus, damit ich sehe, dass er ja auch wieder da ist).

/EDIT
Mir ist noch was merkwürdiges aufgefallen.
Der socket im Client muss ja connect aufrufen, was dann im Server ( bei mir in accepting) auf das acceptor.accept ansprechen soll. Erst wenn da das accept angekommen ist, sollte ja der Client weiterfahren. Nun ist es aber so, dass der Client anscheinend ein connect machen kann ohne dass das beim Server dann weiter geht. (Anhand Debug Ausgaben habe ich das festgestellt). Sprich manchmal connecte sich der Client wirklich und es wird beim Server ebenfalls eine Ausgabe gemacht, oder der Client connected sich iwie mit dem Nirvana.. Aber die Fehlermeldung kriege ich mittlerweilen nicht mehr, obwohl ich prinzipiell nichts grosses am Code geändet habe..

Noch mehr Ideen?

Bis zu dem for( ;; ) ist es sogar genau das gleiche. Und da scheint irgendwie das Problem zu sein.

Sprich socket.connect kommt zurück, ohne das beim Server acceptor.accept anschlägt.
Ich dachte halt, dass der Socket da warten muss, bis er beim Server accepted ist, aber das scheint iwie nicht notwendig zu sein..

btw:
Ich habe mir nochmal ein wenig Gedanken gemacht und ich finde, dass ich das gar nicht asynchron machen muss.. Macht imo keinen Sinn. Der Server wartet ja in einem eigenen Thread auf neue Clients und die Clients müssen warten bist überhaupt mal einen Verbindung zustande kommt, damit sie etwas weiter tun können. (Sprich Befehle vom Server erhalten).

/EDIT:
Achso, nein, sorry. Ich habe ein anderes Query:

tcp::resolver::query query ( server.c_str (), port );

Da wird eine IP und ein Port angegeben. (Also lokale IP und Port 13)
Hmm. Vlt. liegts am Port 13, dass er doch was findet.. Gleich mal testen.

/EDIT:
Nein. Liegt anscheinend auch nicht am Port. Habe ein paar nicht zugewiesene Ports versucht, aber die geben wieder das gleiche Bild..

Du hast da einen Mutex. Kann es sein, dass noch irgendetwas anderes das Ding lockt?

Ja, aber nicht zu dem Zeitpunkt.

Server:

#include <iostream>
#include <boost/asio/io_service.hpp>
#include <boost/asio/ip/tcp.hpp>
#include <boost/thread.hpp>
#include <boost/ptr_container/ptr_list.hpp>

using namespace boost::asio;
using namespace boost::asio::ip;

boost::asio::io_service server_io_service;
boost::ptr_list< tcp::socket > connections;
boost::mutex m;

void accepting ()
{
 for (;;)
 {
   tcp::acceptor acceptor (server_io_service, tcp::endpoint (tcp::v4(), 13) );

   tcp::socket* socket = new tcp::socket ( server_io_service );
   acceptor.accept ( *socket );
   {
     boost::lock_guard<boost::mutex> lock ( m );
     connections.push_back ( socket );
     std::cout << "Accepted...\n";
   }
 }
}	

int main()
{
    boost::thread t(&accepting);
    t.join();

}

Client:

#include <iostream>
#include <boost/array.hpp>
#include <boost/asio/io_service.hpp>
#include <boost/asio/ip/tcp.hpp>

using boost::asio::ip::tcp;

int main(int argc, char* argv[])
{
    try
    {
        if (argc != 2)
        {
            std::cerr << "Usage: client <host>" << std::endl;
            return 1;
        }

        boost::asio::io_service io_service;

        tcp::resolver resolver(io_service);
        tcp::resolver::query query(argv[1], "13");
        tcp::resolver::iterator endpoint_iterator = resolver.resolve(query);
        tcp::resolver::iterator end;

        tcp::socket socket(io_service);
        boost::system::error_code error = boost::asio::error::host_not_found;
        while (error && endpoint_iterator != end)
        {
            socket.close();
            socket.connect(*endpoint_iterator++, error);
        }
        if (error)
            throw boost::system::system_error(error);
    }
    catch (std::exception& e)
    {
        std::cerr << e.what() << std::endl;
    }
}

Mit dem oben stehenden Code kann ich Client starten so oft ich will. Die Verbindungen werden immer angenommen.
Das einzige potentielle Hemmnis das mir auffällt ist der Mutex.

Jetzt war es so, dass ich den acceptor mittlerweilen aus der Funktion gezogen habe und ihn global gemacht habe, damit ich (z.B bei dir in der main vom Server) darauf zugreifen kann).
Wenn ich den acceptor wieder in die Funktion nehme (wie bei dir wieder) scheint es zu gehen, aber ich habe jetzt dafür bei einem Client wieder die ganz oben genannte Fehlermeldung bekommen.. (Die kommt jetzt aber auch nicht jedes mal, sondern wie gesagt sporadisch). Das erste mal funktioniert dafür jetzt wieder anscheinend immer.

Den acceptor habe ich da rausgezogen, damit ich den Thread ganz normal beenden kann. Wie mache ich das denn ohne den? Wenn ich auf den Thread detach aufrufe, dann bekomme ich eine Zugriffsverletzung, welche vom acceptor herrührt.

Ich will sozusagen bei dir in der main des Servers eine Schleife haben, wo auf eine Konsoleneingabe gewartet wird. Und je nach dem kann man mit einer Eingabe dann den Server beenden. Dieser muss dafür aber auch den Thread beenden, was ja nicht geht, wenn der acceptor immer noch wartet. Das geht, wenn ich den acceptor raus nehme und dann kann ich da brav cancel und close auf den acceptor aufrufen und dann kann auch der Thread beendet werden. Allerdings habe ich dann wieder das Problem, dass das connecten nicht jedes mal funktioniert.. (geht ja auch nicht immer, wenn der acceptor in der Funktion ist..)

Mir scheint das alles sehr verzwickt zu sein, die eine Lösung für ein Problem andere Probleme erzeugt, welche nur gelöst werden können, wenn ich wieder auf den Ursprung zurück gehe..

Die synchronen Operationen kann man nicht mit ordentlichen Mitteln unterbrechen.

Wenn man z.B. ein accept sauber beenden will, ist der einzige Weg der mir einfällt, lokal einen Socket zu verbinden, und vorher durch ein Flag dafür zu sorgen, dass kein weiteres Mal accept aufgerufen wird. Man kann den Thread in dem das accept läuft natürlich auch einfach abwürgen, aber das ist mal richtig übel.

Bei async_accept reicht ein acceptor.close() , und ggf. aktive Handler kommen mit operation aborted zurück.

Der Code wird auch nicht wesentlich komplizierter. Dafür bekommst Du für die I/O-Operationen die jeweils optimale Strategie der benutzen Plattform.

Aber ich verstehe trotzdem nicht, warum bei mir der Code nicht geht und warum die diese Fehlermeldung bekomme..
Das blöde ist halt, dass mir das keine Ruhe lässt, bis ich weiss, woran es lag. Ich machs nachher mal mit dem async, aber naja.. Ich will wissen WARUM er mir da keine Verbindung aufbauen kann..

Naja. Auf jeden Fall schon mal vielen Dank für die Hilfe!

Vielleicht meldet sich sonst noch jemand, der Ahung von asio hat.

Nur noch kurz dem Grund, warum ich da synchrone Zugriffe habe. Ich denke halt einfach, warum sollte ich das asynchron machen, wenn ich es ja genau so synchron haben will? Grundsätzlich soll da ja gewartet werden bis etwas kommt und sonst soll einfach nix gemacht werden.

Ich denke halt einfach, warum sollte ich das asynchron machen, wenn ich es ja genau so synchron haben will? Grundsätzlich soll da ja gewartet werden bis etwas kommt und sonst soll einfach nix gemacht werden.

Du hast ja nichts wirklich Synchrones. Du baust Dir der asynchronen Teil umständlich selbst nach, indem Du synchrone Operationen in einen Worker-Thread auslagerst. Zumindest sagtest Du oben, dass Du das accept in einem Thread rennen lassen willst. Du willst es also asynchron.

Zu Deinem Problem: Zeig' nochmal das accept-Dingens, so wie Du es jetzt wirklich hast.

Hier, wies jetzt iwie aussieht:
http://codepad.org/HxdukNNx

Wenn ich im Server die asynchrone Version des accepting laufen lasse, dann kriege ich mit dem Client keine Verbindung mehr. Dann bekomme ich immer den Fehler, den ich bereits genannt habe..

Und beim Teil mit dem Thread kriege ich manchmal eine Verbindung (beim ersten mal immer) und irgendwann dann gar nicht mehr.

btw:
Im synchronen accepting siehst du noch das, was du mit dem Flag angedeutet hast. (hatte ich schon vor deinem Vorschlag so drin ;))

Das erste mal gingen 4 Connects, der 5te ging nicht mehr (gab den obigen Fehler).

Bei dravere scheint der Code (oder besser die Binarys) zu gehen. Also am Code liegts nicht, boost habe ich ebenfalls auf den neusten Stand gebracht, daran liegts auch nicht. OS, hat dravere gesagt hat er WinXP Prof, SP 3 mit/ohne Firewall gehts. Ich habe die gleichen Sachen, aber bei mir gehts nicht. Andere Firewall, wie die Standard von MS habe ich nicht aktiviert.

Ich habe echt keine Idee mehr, an was es liegen könnte. Jemand sonst eine gute (oder überhaupt eine) Idee?

Ich probier das ganze Morgen mal auf einem anderen PC. Langsam nervts mich..

/EDIT:
Auf meinem Netbook funktioniert das ganze ebenfalls wunderbar.. Aber einfach hier nicht.. Anyone ne Idee, welche Einstellungen das scheinen zu sein?

Wie gesagt. An dem Code wirds nicht liegen, sondern an irgendwelchen Einstellungen, aber ich wüsste nicht, was ich, was das anbelangt anderst eingestellt haben könnte..

Danke nochmal an Tachyon!

Zonealarm

EPIC FAIL!

drakon schrieb:

Zonealarm

EPIC FAIL!

Ich hatte das Programm nicht zu meinem Schutz auf dem PC und habe ich daher auch nicht wirklich benutzt.