Stop connecting a bot when 25 minutes queue is active

[Pandiora]

I´m having a lot of accounts and tested the newest release now (1.6 pre2). I installed Mono 4.2.3 on my debian-server (8.1 Jessie) started ASF w/o any parameter. ("--server" fails -> empty.array) After 29 accounts are connected the message "INFO: OnDisconnected() Will retry after 25 minutes..." comes up and would be a nice feature. But after one bot has to wait 25 minutes ASF tries to connect another bot. It would be better to wait 25 minutes globally. Oh btw: This results in an endless loop.

Bot shows error when connecting: "Unable to login to Steam: InvalidPassword". (missing .bin-files I think and to much concurrent connections)

[JustArchi]

I'm not fixing volvo fuckups related to too many accounts being connected.

[Pandiora]

Again: Wait 25 minutes globally and don´t start a neverending loop.

[Pandiora]

Already discussed here: #46 and here: #47 The problem was "fixed" for single bot-instances. But logically if one bot fails to connect with (Invalid Password) and has to wait 25 minutes, ALL bots have to wait 25 minutes. This should be fixed and has nothing to do with Valve Fuckups.

[Rudokhvist]

Actually, no. If one bot fails to connect because of too many attempts id does not means automatically that other bots wouldn't be able to connect too. When I met this problem one of my bot get (Invalid Password) while other bots connected successfully. So "too many attempts for one account" and "too many logins from one IP" is completely separate limitations.

[Pandiora]

Thats not my experience. Because I´m using so much accounts the "Invalid Password Error" is an indicator for to much bots connecting to fast via same ip-address. In this case it wouldn´t make sense to connect other bots when other bots right before failed with the mentioned error. I will test another delay, maybe I can get it fixed this way.

[JustArchi]

What @Ryzhehvost said above is true and that's why I say that nothing is getting done here. It's not a bug of ASF, and it won't be adressed. There's no way to tell what "InvalidPassword" really means (password? captcha? too many failed attempts on acc? per IP?) and I won't be wasting time on addressing such mess. Current mechanism works really well and guarantees that all bots will eventually connect, regardless of the problem (unless invalid password really means that password is invalid, but in this case it's only 1 request per 25 minutes).

[JustArchi]

Your "change" would make it impossible for other bots to connect, even if they are not limited, only because one can't connect because of reason X (which is unknown to ASF). This is worse than current mechanism which assumes that block is on per-bot basis and not per-IP, which is much better as it allows other bots to try connecting while one is blocked.

[JustArchi]

Moreover, if somebody actually changed the password and didn't update it in ASF, it would cause all the bots to never ever connect because of that one account, which is UNACCEPTABLE for ASF, which operates on many bot instances at once.

[JustArchi]

Therefore, point stays - not a bug, and won't be fixed, because there's nothing to fix here. Fix Steam instead to provide proper reason for not being able to connect, and we can discuss the issue further.

[Rudokhvist]

@Pandiora If I understand it right, after you got first "Invalid Password" rest of account would get it too, and all of them would wait 25 minutes, doesn't it means that after 25 minutes those accounts should connect successfully? If there is too much bots and delay between first "Invalid Password" and last bot - then maybe you just need to increase the 25min. timeout?

[Pandiora]

@Ryzhehvost The problem for me is, first bot gets the error and then the next bot connects within the 25 minutes. It looks like this loop of connecting bots raises the 25 minutes-limit over and over again. Last time I used ASF we solved this by using a delay of 5-10s and it worked for me. Now something changed (I have to look up now) and I have the same problems as in the beginning of ASF again ... Yeah increasing the timeout could also fix the problem. It´s just time-consuming to test it over and over again. Oh btw: Asking for a captcha isn´t ip-based. If I connect with a different pc in the same network, I don´t get a captcha.

[Rudokhvist]

If I remember it right - when I had this issue because of too many attempts of incorrect login for one account (actually this was some volvo fuckup, but who cares) - this account got captcha even when logging in from different IP.

[JustArchi]

ASF has rate limiter implemented by default, it's not possible that ASF will be sending more than 1 connect request per 5 seconds, regardless of current situation, whether you have 2 or 222 bots, whether they're all connected or not, or whether steam has fuckups or not. Moreover, it was greatly improved in the meantime, and works like a real rate limiter now, rather than an ugly delay added between sending requests.

So no, concept is still the same, just implementation is better. Perhaps we should increase the delay instead?

[Pandiora]

I think its the delay. I mean this is off-topic, but you can test it yourself with 2 PC´s in your network. You won´t get the same error with ASF and you can log in with accounts that throw this error on the other pc. So anyone of you know how Valve detects you´re using another PC? Maybe this way we could just use another MAC or whatever is send to Valve to circumvent the captcha (if so) or "Invalid Password"-Error.

I´m using the same files for both PC´s (.bin and so on).

[JustArchi]

If we're talking about steam client (because website is totally different thing), then it's based on LoginID which is always the same based on private IP being used by PC.

For now all ASF bots use the same LoginID, so if you start another ASF somewhere else, first one will get disconnected, and they won't interfere with each other.

[JustArchi]

The only thing which comes to my mind is providing each bot with unique LoginID, but that has some drawbacks to consider, as every ASF process should have the same way of calculating the LoginID (same what Valve does with LoginID based on private IP), so it can't be a true random set&forget.

I think we can base it off steam login property.

[Pandiora]

Phew. Okaaaaay, I have to test this shit again. Maybe another reason could be corrupted .bin-Files (again) for whatever reason. When I started using ASF I needed 2 days to generate all .bin-Files step by step. Generate 28 .bin-Files, get InvalidPassword-Error, wait 25 minutes, do it over and over again, until all .bin-Files were generated. Then I found out some .bin-Files were corrupted and it was a lot of work to sort them out and generate them again. I can remember @JustArchi told me the .bin-Files are valid "forever", so I thought they should work with every ASF-Version now.

[JustArchi]

.bin files didn't change from first V0.1 version up to today, they all use same method of generation and upgrades, but that DOES NOT guarantee that Steam network will accept it, as it's totally possible that it can no longer accept old sentry hash, e.g. due to clicking "deauthorize all other computers" in steam client, which effectively kills all ever generated .bin files apart from the one your current steam client uses.

So yeah, those files are the same, their generating is the same, and they should work in all ASF versions, but that does not guarantee that they're valid.

[Pandiora]

Yeah, I never deauthorized an account, so this shouldn´t be a problem. I tested everything again with a 10s delay and it looks like I can connect with more accounts. Everytime I wait those 25 minutes and start ASF (Debian) again, 20-30 more accounts are able to connect. Example: 28 - 56 - 89 (accounts) and so on. It would be a good idea to implement the global config asap for adjusting the delay between login-attempts.

[Pandiora]

I´m not sure why Steam is blocking >100 concurrent connections / logged in accounts, but its possible they limited the max connections to 100-110. Now I´m using 2 instances of ASF on my server with different outgoing IP´s. So far its working without a problem. Maybe theres a cheaper way by using a vpn or proxy but this method was the fastest and most reliable solution for me. Currently I´m working with 7s Delay and to my surprise the bots send me trade-offers - not like yesterday with just one instance.

[JustArchi]

I'd double check if the increased delay is really needed, because by default ASF uses 5 seconds and it should be enough almost in all cases.

Of course, there's no real reason why we couldn't increase that delay to something bigger, but the question is if it's really needed and you didn't spot a classical steam fuckup instead.

[Pandiora]

Yeah, will check it again now. It looks like to much connections just fucked up everything, so it could be possible its the same with the delay.

[Pandiora]

Nearly all accounts connect - but not all. Last 6 accounts can´t connect with "Invalid Password"-Error. Its reproducable and I changed the delay to 7s now, tested again and all accounts connect.

Also, if Steam raises the connection-limit/time in the future, it would be good to have an easy adjustable option for the delay and no need to compile it again.

[JustArchi]

Also, if Steam raises the connection-limit/time in the future(...)

Users in general should not have a choice on that. Things like timeouts suggested by @Ryzhehvost are fine because they vary from user to user, and from one PC to another, but request limiter delay is supposed to be static because we know better what value should be used rather than user who probably doesn't even know what rate limiter is and why it's needed.

Besides, it doesn't change that often, if at all.

[Pandiora]

It´s the same with current configs. Not all settings needs to be touched. This connection-delay would only help users with more then 80-90 accounts, sure.

[JustArchi]

You misunderstand two facts.

There are config properties which can be configured by user, according to his own needs and what he wants to achieve. All of them are in the bot config.

And there are also variables that should never be touched by the user, because we know better what is being used. It's like you'd give user option to modify maximum number of allowed trades for predefined value of 5 to something else - why? User doesn't know what is it, and making such option configurable means that he should configure it according to his own needs, but in fact it should never be touched because the value is based on Steam and Valve, and not on user needs - it's constant which should never be changed, unless in fact Steam changes something, but in this case update of ASF should be released.

For the same reason it's not possible to modify some constants used e.g. in Trading or WebBrowser. User should never touch them, and if you have a strong reason to do so, then you should state that reason here because strong reason also affects other users and not only yourself. For example I can agree that modifying timeout suggested by @Ryzhehvost is OK and should be possible, but I don't consider adding option to change maximum number of allowed connections in connection pool. User should never touch that.

You have a strong reason to modify delay - from 5s to 7s, and I agree that it should be changed (I will change it soon), but making that option configurable is pointless and causes only confusion to potential user, who doesn't know what that option is, why it is 7 seconds, and why he should or should not change it. Do not add to configs things which always should have default values, only for the sake of easier change without a need of recompiling. That value is not even supposed to be changed at all, unless Steam forces it on us. And in this case I'll probably want to do more than just changing the value.

[Pandiora]

You could do the same as in the normal config-files before and warn the user to change the delay if he doesn´t owns more then a defined amount of accounts. Anyway I´m fine with it if the delay stays at 7s now and problem should be solved this way for me.

[JustArchi]

It's too hard to say what delay you need, it's easier to tell what delay will satisfy all scenarios, and for now it's 7 seconds, therefore it stays.