Initially I added check against zero as bullet-proofing for unexpected events, but some accounts actually report 0.
Assume 0 is older than needed, if we don't have information available, we shouldn't jump to conclusions.
- Make use of new UnixFileMode, always one native method we need to maintain less
- Add madness support for it, because new feature of course
- Add optional netstandard target and required compatibility for it, so I can test netf-oriented changes easier
By using ordered list for json body, we can further minimize amount of data sent by getting rid of the index.
We still need previous asset ID, as we send only a subset of real data and server is unable to calculate it from the data sent.
Previously we accepted those after each trade, because the overhead of loading other inventory was too big to leave those pending. Since we have all possible matches at once now, it makes sense to firstly schedule all trade offers, and then just confirm them all at once, especially since confirmations endpoint is horrific and very often problematic, on top of having 10-seconds rate-limiting.
We no longer require 100 tradable items, but rather, 100 total items. We can also further optimize the payload by removing assets where we have no tradable items at all.
Now this is dictated by at least several reasons:
- Firstly, we must have a WebBrowser per bot, and not per ASF instance, as we preserve ASF STM cookies that are on per-bot basis, which are required e.g. for Announce
- At the same time we shouldn't use Bot's one, because there are settings like WebProxy that shouldn't be used in regards to our own server
- We also require higher timeout than default one, especially for Announce, but also Inventories
- Best we can do is optimize that to not create a WebBrowser for bots that are neither configured for public listing, nor match actively. Since those settings need to be explicitly turned on, we shouldn't be duplicating WebBrowser per each bot instance, but rather only few selected bots configured to participate.
We should announce to the listing at least each 60 minutes, but we should do it faster if we know that our inventory has changed. With this logic we can report in up to 1 minute since the change, which should provide very up-to-date state, but at the same time we still limit amount of announcements to not more than one per 5 minutes.
* Start work on extracting remote communication
* ok
* Dockerfile fixes
* More fixes
* Prepare /Api/Announce and /Api/HeartBeat
* Decrease publish race conditions
* OK
* Misc
* Misc
* Misc
* Move Steam group part back to ASF core
* Finally implement match actively v2 core
* Update RemoteCommunication.cs
* Use single round exclusively, report inventories more often
* Use randomization when asking others for assetIDs
* Add support for license and crowdin
* Kill dead code
* Fix return type of inventories
* Fix responses for good
* Unify old backend with new
* Report whole inventory, always
Helps with optimization on the backend side in terms of inventory fetching
* Update RemoteCommunication.cs
* Determine index of each asset and tell server about it
* Update AnnouncementRequest.cs
* Fix ASF screwing up with the order
* Fix warnings
* Misc rename
* Final logging touches
