toddw123 / RotMG_Clientless

Compatible with version X16.0.0
MIT License
11 stars 4 forks source link

Check logged in every x minutes #39

Closed jalius closed 7 years ago

jalius commented 7 years ago

So, sometimes there is an error with your connection and one of your client disconnects without triggering the reconnect method. So I added a little code to check every 600 seconds if clients are logged in from the main while(run){} method. If they aren't logged in, we start them again using client.start()

    if (i == 1200) //increment i every time while(run) method is checked
    {
        i = 0;
        for (int i = 0; i < (int)clients.size(); i++) //for every client, check if they are in use. if they aren't, start them again
        {
            Client *c = &clients.at(i);
            std::string rawxml = curl_get("http://realmofthemadgodhrd.appspot.com/char/list", c->guid, c->password);
            std:size_t found = rawxml.find("in use");
            if (found != std::string::npos)
            {
                Sleep(1000); //sleep added because cpu usage becomes quite high when checking account in use rapidly
                continue;
            }
            else
            {
                if (!clients.at(i).start())
                {
                    printf("Error starting client #%d\n", i);
                }
                else
                {
                    printf("client #%d is running\n", i);
                }
            }
            Sleep(1000);
        }
    }

Is this good or something you might consider a bandage fix? What other way would you go about running a check for clients being connected? Is this even a feature that we want in clientless program, or would you rather have some other solution to the issue of clients being disconnected sometimes such as sending a hello packet possibly (it's cheaper resource wise, but im not sure how we determine if bot is logged in)?

edit: i just realized you have changed the clients to unordered map, but my idea still remains.

Zeroeh commented 7 years ago

Something like this already exists in clientless.cpp http://prntscr.com/eknnxx Just need to add reconnect if client is disconnected.

toddw123 commented 7 years ago

Look at the other branches. The main branch i dont do any kind of reconnect except if the server sends one. If you look at the lootbot branch you will see that the client reconnects if it gets disconnected. I also have unpublished code that is very similar to the lootbot branch where it reconnects when disconnected.

jalius commented 7 years ago

@Zeroeh this is the loop in which my code runs. @Toddw123 what will you use to determine if the client is connected? Something to do with sockets or checking char/list

jalius commented 7 years ago

I know you call recon method on failure, but sometimes we disconnect without a failure (maybe due to my poor connection).

toddw123 commented 7 years ago

you are connected as long as you are getting packets, if you arent getting packets it means you are disconnected. No need to do any checks other then that. Look at the lootbot code. If the client gets a failure packet, reconnect. If the client gets 0 bytes or 1 byte when trying to read a packet (which means there was a problem), reconnect. No need to get the char/list again, no need to do anything outside of the client except call reconnect if there are no more packets coming in.

Although along those lines of getting 1 byte or 0 bytes, generally you only get 0 bytes if the server is down. So that is why in the last lootbot code i have it switch servers in those cases.

But theres more logic then just what im saying here, what im trying to do is give you an overview of the basic idea behind it. Which that basic idea is: getting packets = connected, not getting packets = not connected. Thats the benefit of the servers being TCP instead of UDP. TCP is much easier to determine if you are connected or not.

Zeroeh commented 7 years ago

@bluuman As todd said, you can rely on tcp to tell if the clients are connected since tcp requires all packets to be sent in order. If something isn't right it will shut down the receive thread (but you can add your reconnect code before it does that)