Niektóre błędy zawodzą za każdym razem. Inne zawodzą według harmonogramu. Błąd podpisywania w Huobi i HTX naprawiony w wersji 2026.9 był tego drugiego rodzaju, co znacznie utrudniało jego namierzenie: na hoście działającym poza strefą UTC żądania prywatne zawodziły przez część każdej doby, a przez resztę działały poprawnie, co wygląda dokładnie jak przerywany problem z uwierzytelnianiem, dopóki ktoś nie zauważy, że wzorzec pokrywa się z zegarem.
Znacznik czasu zbudowany z dwóch różnych zegarów
Zarówno Huobi, jak i HTX wymagają, aby podpisane żądanie zawierało znacznik czasu w UTC, w formacie yyyy-MM-ddTHH:mm:ss. Procedura podpisywania w TsgcWS_API_Huobi_Base, wspólna dla TsgcWSAPI_Huobi i TsgcWSAPI_HTX, budowała ten znacznik czasu z dwóch różnych źródeł: część dotycząca daty pochodziła z lokalnego zegara systemowego, a część dotycząca czasu pochodziła z UTC. Przez większą część dnia na większości maszyn lokalna data i data UTC mają tę samą wartość, więc nic nie wyglądało źle. W okolicach północy UTC, na każdym hoście, którego lokalne przesunięcie strefy czasowej umieszczało go po drugiej stronie tej granicy, data i czas przestawały się ze sobą zgadzać, podpis obliczony samodzielnie przez Huobi nie pasował, a żądanie zostawało odrzucone.
Poprawka pobiera zarówno datę, jak i czas z tej samej wartości UTC:
uses
sgcBase_Helpers;
var
vUTC: TDateTime;
vTimeStamp: string;
begin
vUTC := sgcGetDateTimeAsUTC;
vTimeStamp := FormatDateTime('yyyy-mm-dd', vUTC) + 'T' +
FormatDateTime('hh:nn:ss', vUTC);
end;
Nie ma tu nic do skonfigurowania. TsgcWSAPI_Huobi i TsgcWSAPI_HTX wywołują tę samą procedurę podpisywania, więc obie są naprawiane jednocześnie:
uses
sgcWebSocket, sgcWebSocket_APIs;
var
oHuobi: TsgcWSAPI_Huobi;
begin
oHuobi := TsgcWSAPI_Huobi.Create(nil);
oHuobi.Client := oClient;
oHuobi.Huobi.ApiKey := 'your_api_key';
oHuobi.Huobi.ApiSecret := 'your_api_secret';
oClient.Active := True;
// Authentication now signs with a timestamp taken entirely from UTC.
oHuobi.SubscribeOrderUpdates('btcusdt');
end;
Jeśli w Twoich logach prywatne żądania Huobi lub HTX zawodziły w sposób, który zdawał się pojawiać i znikać bez wyraźnej przyczyny, bardzo prawdopodobnie to właśnie jest tego powodem, zwłaszcza jeśli Twoje serwery nie działają w strefie UTC.
Utrata prywatnych subskrypcji po ponownym połączeniu
Huobi był też jednym z kilku klientów giełdowych dotkniętych osobnym błędem ponownego łączenia, naprawionym w tym samym cyklu: po tym, jak WatchDog nawiązywał ponowne połączenie, prywatne subskrypcje, zamówienia, salda, realizacje, nie były odtwarzane. Samo ponowne połączenie kończyło się sukcesem i było tak logowane, więc nic nie wskazywało na to, że prywatne kanały danych, które odbierałeś przed rozłączeniem, teraz po cichu zniknęły. Ich odtwarzanie jest teraz częścią tej samej ścieżki ponownej subskrypcji, która już wcześniej przywracała publiczne subskrypcje danych rynkowych po ponownym połączeniu.
Aktualizacja
Obie poprawki działają od razu po aktualizacji. Nie ma żadnej właściwości do ustawienia ani kodu do zmiany, podpis jest po prostu teraz poprawny, a odtwarzanie po ponownym połączeniu obejmuje teraz również Twoje prywatne subskrypcje.
Pytania, uwagi albo pomoc przy migracji? Skontaktuj się z nami — odpowie Ci osoba, która napisała ten kod.
