Ботове и API за залагане: автоматизация без заключена сметка

Къде правилото прави разграничение

Автоматизацията е една линия сред няколко в по-широкия набор от професионални методи за залагане, разгледани на този сайт, и има собствена страница, защото правилата тук са по-конкретни от „sharp залагащите ползват софтуер“. Съкратеното форумно значение на „бот“ е едно нещо: софтуер, който слага залози. Условията на Betfair са по-точни. Клауза 12.1.4 изброява сред дейностите, които третира като подозрителни, залог, направен „otherwise than through the Account holder placing each Bet manually“, което, прочетено само, би обхванало всеки скрипт, писан някога. Не се чете само: същата клауза носи собственото си изключение, посочено за избягване на съмнение, че залозите, направени „via the Application Programming Interface (API)“, не са включени. Съберете двата откъса и разделението е точно: скрипт, който щрака из обикновения уебсайт, е онова, към което е насочена клаузата, а скрипт, който говори с API, е изключението, което самата клауза назовава.

Една бележка встрани: „бот“ върши много работа в това изречение, а думата всъщност не се появява в клаузата. Юристите на Betfair са написали „otherwise than through the Account holder placing each Bet manually“, което е по-дълъг начин да се каже същото, но много по-трудно изречение за невярно цитиране. Както и да е, обратно към това какво означава за вас.

Затова правилото не е „ботовете са забранени“ и не е „ботовете са наред“. То е по-тясно: неофициален скрипт, който работи със сайта като много бързи ръце, попада в клауза за подозрителна дейност, а същата логика, свързана с официалния API, попада в изключението. Който търгува ръчно по стълбата, и скрипт, който прави същото през API, се третират различно от един и същ документ, а разликата е във вратата, не в стратегията зад нея.

Какво да тествате, преди ключ Live да получи средства

Всеки, който прави бот, иска да прескочи към слагането на залози. Честният ред е обратният: докажете логиката върху данни, нарочно по-бавни от реалното време, при най-малкия размер на залога, който пазарът позволява, преди платен ключ или сериозен банкрол да са наблизо.

Този диапазон, една секунда в най-добрия случай и до три минути в най-лошия, не е грешка от закръгляне, която да подминете. Коефициент, който скриптът е видял за разумен, може да се е отместил далеч, когато скриптът действа, и няма пясъчник, който да смекчи това: според собствената документация на Betfair няма тестова среда, в която някой да тества, без да използва реални средства. Всеки залог, който слага ключ Delayed, е истински залог с реален резултат, затова най-малкият размер на залога, който пазарът позволява, е единственият разумен начин да се мине този етап.

Хипотетичен пример, с всички числа измислени само за пресмятането. Да кажем, че скрипт следи коефициент 2,10, решава да заложи back и в същия момент API връща снимка на 180 секунди. За три минути могат да станат гол, червен картон или късно отпадане, така че коефициентът, който скриптът смята, че взима, и коефициентът, който наистина се предлага, когато поръчката пристигне, могат да са две различни числа. Никаква хитра логика нагоре по веригата не поправя решение, построено върху остаряла информация; самото закъснение, а не стратегията отгоре, е първото нещо, което си струва да се тества.

Пазарът е само половината от картината; другата половина е потокът, на който ботът всъщност реагира, а скрипт, построен върху оскъдна история, ще сбърка при който и да е ключ. Проверете сметките ръчно с калкулатор, преди да се доверите на собствените числа на скрипта, и не забравяйте, че комисионата на борсата пак се удържа от всеки печеливш залог; какво прави тя с нетните числа на бота си струва да се прочете, преди стратегия да бъде обявена за успешна на хартия.

Ограниченията, около които скриптът трябва да е проектиран

Нищо от това не е въпрос дали автоматизацията е позволена. То е за тавана, който самото API поставя върху поведението на скрипта, изложен в ясни числа, а не оставен на догадки. Четири от тях имат най-голямо значение, докато скриптът още е на чертожната маса, и заедно със собствения прозорец на закъснение на ключа Delayed по-горе са числа, които Betfair може да променя; проверете текущите условия, преди да проектирате производствен код около което и да е от тях.

• Таван от 200 точки за заявките за пазарни данни. Цената се събира по пазарите и по вида поискани данни; надхвърлянето на общата стойност връща грешка вместо данните.
• Таван от 3 едновременни заявки за повикванията за поръчки и позиции. Проверка на текущите поръчки, печалбата и загубата или приключените поръчки повече от три пъти едновременно, докато предишни повиквания още текат, се отказва, а не се нарежда на опашка.
• Таван от 1000 инструкции в секунда за слагане, отмяна, обновяване или замяна на поръчки. Той покрива цялата сметка през всички отворени връзки, а не един скрипт сам по себе си.
• 20-минутна блокировка след твърде много неуспешни вписвания. Всеки следващ опит за вписване се отказва автоматично за този период, каквато и да е причината за предишните неуспехи.

Втори хипотетичен пример, и той е този, който наистина хваща хората. Скрипт, чието вписване има грешка, не успява да поднови сесията си навреме и повтаря опита в тесен цикъл, вместо да изчака. Двайсет минути са горе-долу едно полувреме във футбола; задействайте блокировката при начален удар и скриптът ще пропусне повече от мача, отколкото някога е уловил. Поправката е по-скучна от историята: пазете сесията и приемайте неуспешното вписване като причина да спрете, а не да опитате веднага отново.