How Coinigy has solved 422 blues...

[allanster]

Coinigy has seemed to gotten around this issue buy allowing multiple "sub-keys" and rolling through them. I would like to know if this could potentially fix these problems with Gunbot as well. Experienced users please give me your thoughts. Thanks!

https://blog.coinigy.com/2016/07/sub-keys-now-enabled-for-poloniex-and-kraken/

[Snowman418]

Not necessary to use subkeys. You just need to use the larger API calls such as returnTicker and returnOrders, instead of trying to pull individually for every pair.

Gunthy's implementation is inefficient.

[allanster]

Snowman418,

That well may be correct, I don't know enough to debate, seems logical though and hopefully (if this is a concern) it will be addressed. In the meantime I like to drive the nail with many hammers, so if Coinigy has had success with this same issue by implementing rolling subkeys, then it stands to reason this would help Gunbot as well.

Last night I implemented ELECTRIC_WIZARD'S tip below on my Windows install and it has dramatically improved this issue for me...

In your Gunbot folder you will also find a file called ALLPAIRS-params.js and yes, these settings will affect all your pairs.

I recommend you include the following lines between the curly-braces (that is these: {   }):

BOT_SLEEP_DELAY: ((1001)*90*(Math.random()*0.3+0.7)),
BOT_MAX_LIFETIME:999999999,// overall bot lifetime(koef*min),
BOT_ON_FAIL_DELAY:((1001)*120*(Math.random()*0.3+0.7)),

This randomizes your pairs so to minimize them all calling Polo at once, which will reduce your '422' and '429' error codes at times of peak server traffic. If you are suffering from these, you will want to increase the numbers between the asterisks, so perhaps 90 becomes 120 and 120 becomes 180, or you can experiment like the newly-weds you are until you find what works best for you.

[allanster]

I've now looked into API and am curious why this isn't being implemented?...

returnTradeHistory - Returns the past 200 trades for a given market, or up to 50,000 trades between a range specified in UNIX timestamps by the "start" and "end" GET parameters.

source -https://poloniex.com/support/api/

I've also familiarized myself now with restrictions of 6 API calls per second by IP.. Coinigy employs multiple IP addresses so if your API subkeys were rolling through while simultaneously rolling through their IP's, this would explain how this is helping eliminate this issue with their users.

Coinigy's current (subject to change at any time) list... 104.197.144.74, 104.154.21.31, 104.198.237.125, 104.197.40.47, 146.148.40.57, 104.154.38.52, 104.197.15.96, 104.198.238.180

This also means there is probably merit to the proxy service the member was recently posting on here. By merit I mean to the proxy idea. I don't have any opinion as far as their service. If they want to charge and users want to pay, power to them. Obviously I would rather come up with free method.

[soyab0007]

AFAIK, coinigy is not instant in updating trades... it takes few seconds to reload buy/sell orders

[allanster]

I haven't noticed any lag on Coinigy but I wasn't suggesting Gunbot support trades there. My point is they have found a way to reduce 422 errors by employing multiple sub keys and multiple IP addresses. Poloniex restricts users to maximum of 6 API calls per IP. Said another way... 6 calls per API per IP. So what they've done is made it where each call is done from a different IP and a different key.

The member hawking the 0.1 BTC service on here says they are using a proxy to get 3s/3s timing in Gunbot without being banned. I'd wager their using Squid to do this. There's nothing special about just using a normal proxy, but Squid can be configured to roll each query through a different IP, thus flying under the radar.

I don't know how Gunthar feels about this, he's seemed to have a pretty firm stance on not violating the exchange restrictions. Technically this doesn't violate rule. This morning I came up with ways to limit connections to 6 for Poloniex IP's in Windows 10. This way I can test more aggressive polling without violating rules.

But I'd like to know how many "calls" each pair makes per loop. I'm snipping sessions that may not need to be limited because I don't know this answer. I may have to packet capture but I'd rather not have to take the time if someone in here knows the answer.

[allanster]

Solved! (free) -> https://gunthy.org/index.php?topic=570.msg2966#msg2966