Archisteamfarm: Ability to select the protocol for WCF

[CoobieXD]

I'm an amateur web-developer, wrote a kind of an add-on server in conjunction php+js, which runs through SOAP with http://127.0.0.1:1242/ASF?wsdl service.

Because of this, I have to work with the old version of the ASF 2.1.6.8, and I can not upgrade to a newer, due to the fact that the WCF is now working through net.tcp protocol.

Is it possible in a future version, in the configuration to make a choice between net.tcp and http protocol?

_P.S. Sorry for my english and possible technical errors in the wording._
_Thanks in advance for your reply._

[judgegr]

IIRC, it was changed due to some security concerns, check this: #373

[CoobieXD]

Yes, I have seen this issue.

But unfortunately I did not find any possible way to connect to net.tcp through php/js, so I wanted to ask to make such an option (_"on our own risk"_), because other means of interaction I have not found :(

[JustArchi]

I'm not super happy with this, but it's valid enhancement so I'm putting it on wishlist.

It'd be best to drop SOAP and instead execute ASF.exe with --client parameter and commands to execute, you can do this with exec().

[CoobieXD]

Thank you so much!

Yes, earlier I used exactly the exec(), but in the course of work I often receive a stack of dozens of commands (in particular redeem).
I wrote a parser keys from giveaways on some web-forum, and here to me is very important the speed and performance (every call to exec() launches a new task and is very costly).

I did some tests and found out that, unfortunately, the exec does not suit me.

50 consecutive calls via exec():

50 * ( ASF_Init[~0.8s] + HandleCommand[~0.4s] ) = ~60s

50 consecutive calls via SoapClient():

50 * ( SOAP_Connect[~0.05s] + HandleCommand[~0.4s] ) = ~22.5s

_^ almost three times faster_

Plus, I'm using a slightly different algorithm for distributing keys, so that I can not use the union command type ASF.exe --client "command1" "command2"
I keep in the database a list of games that are on each of the accounts. Therefore, at the first "AlreadyOwned" status I redirect key to where this game has no, it is much faster.

An example of normal operation sequence of the ASF at the distributing keys:

2017-01-31 17:30:00|ASF-896|INFO|ASF|HandleCommand() Answered to WCF command: redeem ZZZZZ-ZZZZZ-ZZZZZ with: 
<001> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<002> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<003> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<004> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<005> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<006> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<007> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<008> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<009> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<010> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<011> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<012> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: DuplicatedKey | Items: [13740, ArchiGame]

_^ total: ~6 seconds, and the key was redeem by someone else_

Example sequence ASF works with my algorithm:

2017-01-31 17:30:00|ASF-896|INFO|ASF|HandleCommand() Answered to WCF command: redeem^ 001 ZZZZZ-ZZZZZ-ZZZZZ with: 
<001> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: AlreadyOwned | Items: [13740, ArchiGame]
2017-01-31 17:30:01|ASF-896|INFO|ASF|HandleCommand() Answered to WCF command: redeem^ 009 ZZZZZ-ZZZZZ-ZZZZZ with: 
<012> Key: ZZZZZ-ZZZZZ-ZZZZZ | Status: OK | Items: [13740, ArchiGame]

_^ total: ~1 second with soap(~3 seconds with exec), and the key was redeem by me_

[JustArchi]

Why you won't use forwarding? ASF is smart enough to forward the game to the bot that doesn't own it yet automatically.

[CoobieXD]

Yes, but for that he goes through the accounts, and therefore they quickly go into the cooldown:

<001> Key: QQQQQ-QQQQQ-QQQQQ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<002> Key: QQQQQ-QQQQQ-QQQQQ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<003> Key: QQQQQ-QQQQQ-QQQQQ | Status: AlreadyOwned | Items: [13740, ArchiGame]
<004> Key: QQQQQ-QQQQQ-QQQQQ | Status: OK | Items: [13740, ArchiGame]

<001> Key: WWWWW-WWWWW-WWWWW | Status: AlreadyOwned | Items: [13740, ArchiGame]
<002> Key: WWWWW-WWWWW-WWWWW | Status: AlreadyOwned | Items: [13740, ArchiGame]
<003> Key: WWWWW-WWWWW-WWWWW | Status: AlreadyOwned | Items: [13740, ArchiGame]
<004> Key: WWWWW-WWWWW-WWWWW | Status: OK | Items: [13740, ArchiGame]

<001> Key: EEEEE-EEEEE-EEEEE | Status: AlreadyOwned | Items: [13740, ArchiGame]
<002> Key: EEEEE-EEEEE-EEEEE | Status: AlreadyOwned | Items: [13740, ArchiGame]
<003> Key: EEEEE-EEEEE-EEEEE | Status: AlreadyOwned | Items: [13740, ArchiGame]
<004> Key: EEEEE-EEEEE-EEEEE | Status: OK | Items: [13740, ArchiGame]

... +7 new keys

<001> Key: AAAAA-AAAAA-AAAAA | Status: OnCooldown
<002> Key: AAAAA-AAAAA-AAAAA | Status: OnCooldown
<003> Key: AAAAA-AAAAA-AAAAA | Status: OnCooldown
<004> Key: AAAAA-AAAAA-AAAAA | Status: OK | Items: [13740, ArchiGame]

Is not it so?

[JustArchi]

No, one AlreadyOwned should be enough to guess which account has which game, unless you're using some outdated ASF version that doesn't support this enhancement.

[CoobieXD]

_^ on the latest version 2.2.1.9_

[JustArchi]

Which means that for some reason with that particular game there is a mismatch between packageID reported by key and packageID that bot owns. Happens, but it should happen rarily.

[CoobieXD]

Strangely, it seemed to me that this happened with absolutely every game, which I tested.

Maybe it makes sense to match the name of the game(or its hash-sum) instead of packageID?

[JustArchi]

You can't match appID, as key is tied to packageID, and you can't match name of packageID either, as it can be anything, including "Humble 100% Salt Bundle 2015" instead of game names.

[CoobieXD]

If so, indeed :c

But why this can happen with every game on the latest version of ASF in my case?

[JustArchi]

In order to answer that question we'd need to check content of OwnedPackageIDs of given bot. If you have programming knowledge, you can just dump all packageIDs from it and check if it's there (probably not), and if not, as which packageID.

[JustArchi]

Done and it looks like all 3 work on both Windows and Mono.

NetTcp binding is still recommended due to additional extra security, I'll add proper notice to wiki when I decide to document this property.

[CoobieXD]

On the last stable version 2.2.2.4 by passing on http://127.0.0.1:1243/ASF I have got that response:

WCF Error - "Metadata publishing for this service is currently disabled"

It looks like only NetTcp works and at the same time conflicts with BasicHttp and WSHttp (it's just my subjective speculation).
But at the same time everything works fine in the old version 2.1.6.8 (BasicHttp only) with the same configurations.

I am trying to solve this problem for two days but it still does not work. Is that problem inside the ASF? Or in my work?

[JustArchi]

Since when metadata publishing is required to use ASF WCF? Yes, that option was removed, because metadata publishing is not required to make a connection, it's an extra that allows discovering endpoints, but not a core feature.

Is that problem inside the ASF? Or in my work?

Can you connect to ASF --server from ASF --client? Then there is no problem in ASF. You're referring to extra feature that is not needed to make ASF WCF work - this is what typically happens when you connect to ASF WCF service from a client that doesn't know how to communicate with it, e.g. your browser.

I might want to add metadata back anyway, as long as it works on Mono.

[CoobieXD]

If everything works fine, I would not pay attention for that :(

The server starts good, but at client connection(_php_) I get an error that does not occur in the old version(_when metadata is present_):

$client = new SoapClient('http://127.0.0.1:1242/ASF');

Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://127.0.0.1:1242/ASF' : Premature end of data in tag HTML line 1 in Z:\home\wcf_http_test.php:17 Stack trace: #0 Z:\home\wcf_http_test.php (17): SoapClient->SoapClient('http://127.0.0....') #1 {main} thrown in Z:\home\wcf_http_test.php on line 17

[JustArchi]

Let me know if latest appveyor build with basic metadata bits fixed the issue for you - this will tell me if this is enough or I need to add mex bindings as well. Current version works flawlessly on Mono.

[CoobieXD]

The issue is solved, thank you, that is enough :+1:

[JustArchi]

Good to hear it, I'm keeping this code then, after a small cleanup. Thanks for testing!