|
kalkulatorix (OP)
|
 |
November 17, 2014, 11:48:20 PM |
|
Ach, hättest Du doch was gesagt! Ich hab doch den meisten Kram schon in Java am Laufen! Das wär doch ne Kleinigkeit gewesen, Dir zu helfen...
Kein Problem. Ist ein toller Synergieeffekt. Muss auch für die Arbeit C# lernen, jede Stunde die ich in den Bot in C# investiere, zählt somit doppelt. Beobachte jetzt schon eine Stunde, wie schön die Threads ineinandergreifen! Das Traden habe ich noch deaktiviert, da braucht es noch einige Tage Testläufe. |
12313123
|
|
|
|
Darkwinde
|
|
November 23, 2014, 01:48:01 PM |
|
API Stabilität steht momentan bei mir im Hauptfokus. Ich entdecke immer wieder kleine Eigenheiten der Börsen die das Fehlerhandling immer wieder auf die Probe stellen. Der Bot selber hat keine Abstürze aber wenn es natürlich in einer Schleife endet ohne Exit Strategie ist das natürlich doof. Aber sind zum Glück selten geworden  Antizyklus Einheit ist auch voll am werkeln. Nach der letzten Woche wo nahezu alle Coins verloren haben geht es nun bergauf und direkt auf den Ausgangszustand zu. Arbitrage rödelt vor sich hin, wobei ich mir selber ein Bein gestellt habe als ich nicht über den Bot habe traden lassen sondern eine manuelle Order stehen und vergessen hatte. Jetzt hat zwar der Bot erkannt dass ich mit mir selber traden wollte, hat aber vergessen nicht zu traden. Naja und die dauerschleife war geboren  ansonsten konstantes Einkommen von 1% des Invest pro Tag. Bot traden jetzt an 4 Exchanges Parallel was auch nette Race Conditions verursacht hat aber auch die sind nun aufgelöst. Geduld ist alles mittlerweile Schaue ich nur noch 1x am Tag noch ob was passiert ist. |
|
|
|
|
kalkulatorix (OP)
|
|
November 24, 2014, 02:27:53 PM |
|
API Stabilität steht momentan bei mir im Hauptfokus. Ich entdecke immer wieder kleine Eigenheiten der Börsen die das Fehlerhandling immer wieder auf die Probe stellen. Was mir dabei immer wieder Probleme macht: ( aber nicht bei allen Börsen ) Die Rundung im Betrag. Die Beträge rechnet der Bot ja selbst, und bei manchen Börse ergibt das einen Fehler, wenn der Betrag zu viele Nachkommastellen hat, andere Börsen runden wieder automatisch. Damit ich das Problem umgehe habe ich die Anzahl der Kommastellen als Eigenschaft vom Markt definiert, und runde die Beträge, bevor ich sie an die Börse sende. Das braucht etwas an Wartungsaufwand, und immer wieder Kontrolle, falls die Börse die Kommastellen ändert. Mit den Preisen habe ich keine Probleme, die kommen vom Orderbuch, und haben deswegen nie zu viele Kommastellen. Ansonsten gibt es ein paar mal am Tag Internetausfälle. Wenn die geforderten Daten nicht kommen, werden die im Bot gespeicherten Daten gelöscht, damit nicht mit veralteten Informationen gehandelt wird. Manche Börsen zicken noch mit dem nonce herum. BTC-e ist da lustig, diese Börse sendet bei falschem nonce jenen, welchen sich die Börse erwartet. Da mit dem nonce ist immer dann ein Problem, wenn 2 Bots mit demselben Key / Secret aktiv sind, da hole ich einfach einen zweiten Key ( bei BTer geht das nicht, da kann immer nur einer aktiv sein, als Ausgleich nehmen sie es dort mit dem nonce nicht so genau..... ) Die Dreicksarbitrage ist mittlerweile vollständig in C# implementiert. Als Nächstes programmiere ich Auswertungen, einmal je Börse und einmal gesamt über alle angebundenen Exchanges hinweg. Bei BTer war die Dreiecksarbitrage am Wochenende irrsinnig aktiv, da habe ich komplett die Übersicht verloren. Im Doge/Btc Markt waren gravierende Differenzen zwischen BTer und Cex, dafür hätte ich zwar noch den PHP Bot gehabt, habe ihn aber nicht gestartet wegen mangelnder Orientierung, wo meine Coins gerade sind.  @Darkwinde: Wobei hast Du ein Stabilitätsproblem? |
12313123
|
|
|
|
Darkwinde
|
|
November 24, 2014, 02:39:02 PM |
|
API Stabilität steht momentan bei mir im Hauptfokus. Ich entdecke immer wieder kleine Eigenheiten der Börsen die das Fehlerhandling immer wieder auf die Probe stellen. Was mir dabei immer wieder Probleme macht: ( aber nicht bei allen Börsen ) Die Rundung im Betrag. Die Beträge rechnet der Bot ja selbst, und bei manchen Börse ergibt das einen Fehler, wenn der Betrag zu viele Nachkommastellen hat, andere Börsen runden wieder automatisch. Damit ich das Problem umgehe habe ich die Anzahl der Kommastellen als Eigenschaft vom Markt definiert, und runde die Beträge, bevor ich sie an die Börse sende. Das braucht etwas an Wartungsaufwand, und immer wieder Kontrolle, falls die Börse die Kommastellen ändert. Ich bin da sehr gnadenlos Coins haben 8 Nachkommsstellen. Nicht mehr nicht weniger und damit rechne ich bzw. sende es auch so an die Börsen das scheint zumindest den Exchanges nicht ungelegen zu kommen. @Darkwinde: Wobei hast Du ein Stabilitätsproblem?
BTer scheint mir immer mal wieder falsche oder keine OrderID's zu übergeben was ich zwar abfange aber irgendwo doch schlupflöcher sind. Im schlimmsten fall hatte ich es sogar mal das die API so eine Latenz hatte, dass er die Order Akzeptiert hatte, beid er Börse angelegt wurde aber erst nach 1 Minute via API der Status abrufbar war. Da wurder der Bot natürlich zu recht ungemütlich, hat meien Datenbank bereinigt um kurze Zeit später eien "Lost Buy Order" wieder zu finden mit gleicher ID.... GRRRRRRRRRRRRRRRRRRRR |
|
|
|
|
kalkulatorix (OP)
|
|
November 24, 2014, 04:24:55 PM |
|
@Darkwinde: Wobei hast Du ein Stabilitätsproblem?
BTer scheint mir immer mal wieder falsche oder keine OrderID's zu übergeben was ich zwar abfange aber irgendwo doch schlupflöcher sind. Im schlimmsten fall hatte ich es sogar mal das die API so eine Latenz hatte, dass er die Order Akzeptiert hatte, beid er Börse angelegt wurde aber erst nach 1 Minute via API der Status abrufbar war. Da wurder der Bot natürlich zu recht ungemütlich, hat meien Datenbank bereinigt um kurze Zeit später eien "Lost Buy Order" wieder zu finden mit gleicher ID.... GRRRRRRRRRRRRRRRRRRRR Nur eine Idee, da ich keine Rückmeldungen verarbeite ( aber doch die Fehler mitlogge ), kann da vielleicht ein Überlauf vorliegen? Bei manchen Exchanges sind die OrderIDs schon sehr hoch, die passen in keinen int32 mehr, da braucht es schon 64 bit. Wenn die Order ID über 2.147.483.647 liegt, passt das nicht mehr in einen 32 bit langen integer. PHP hat zwar kein strenges Typkonzept, aber irgendwie muss das PHP dann ja doch rechnen. |
12313123
|
|
|
|
Darkwinde
|
|
November 24, 2014, 04:30:18 PM |
|
@Darkwinde: Wobei hast Du ein Stabilitätsproblem?
BTer scheint mir immer mal wieder falsche oder keine OrderID's zu übergeben was ich zwar abfange aber irgendwo doch schlupflöcher sind. Im schlimmsten fall hatte ich es sogar mal das die API so eine Latenz hatte, dass er die Order Akzeptiert hatte, beid er Börse angelegt wurde aber erst nach 1 Minute via API der Status abrufbar war. Da wurder der Bot natürlich zu recht ungemütlich, hat meien Datenbank bereinigt um kurze Zeit später eien "Lost Buy Order" wieder zu finden mit gleicher ID.... GRRRRRRRRRRRRRRRRRRRR Nur eine Idee, da ich keine Rückmeldungen verarbeite ( aber doch die Fehler mitlogge ), kann da vielleicht ein Überlauf vorliegen? Bei manchen Exchanges sind die OrderIDs schon sehr hoch, die passen in keinen int32 mehr, da braucht es schon 64 bit. Wenn die Order ID über 2.147.483.647 liegt, passt das nicht mehr in einen 32 bit langen integer. PHP hat zwar kein strenges Typkonzept, aber irgendwie muss das PHP dann ja doch rechnen. Orderid: 2.843.917 da ist noch Luft  außerdem geht das direkt in ein String über. Bekomme dann auch mal sowas 2599382 was weit unter dem aktuellen Bereich liegt. Keine Ahnung was da schief läuft, ich logge jetzt erstmal jeden scheiß mit...ist halt müßig da es nicht immer passiert, aber extrem häufig seit den Wartungsarbeiten am Wochenende |
|
|
|
|
Darkwinde
|
|
November 24, 2014, 07:09:09 PM |
|
Das kann jetzt mittlerweile echt nurnoch ein API Server Überlast Szenario sein. So unregelmäßig und an unterschiedlichen Stellen das kommt. Und wenn ich noch weitere identische Calls nur mit nem Delay absetze werden diese mit gleicher OrderID korrekt beantwortet. Ich schreibe später mal ein Script das permanent kauft, Status abfragt und Cancelt um das nachzuweisen. Bekommen die BTer Jungs ein nettes Ticket von mir |
|
|
|
|
kalkulatorix (OP)
|
|
November 25, 2014, 12:17:57 AM |
|
Das kann jetzt mittlerweile echt nurnoch ein API Server Überlast Szenario sein. So unregelmäßig und an unterschiedlichen Stellen das kommt. Und wenn ich noch weitere identische Calls nur mit nem Delay absetze werden diese mit gleicher OrderID korrekt beantwortet. Ich schreibe später mal ein Script das permanent kauft, Status abfragt und Cancelt um das nachzuweisen. Bekommen die BTer Jungs ein nettes Ticket von mir Von mir bekommen die von Bter auch ein Ticket. Vor allem der BTC/CNY Markt ist dort zeitweise vermurkst. Zeitweise ein falsches Orderbuch, bis zu 5% daneben. Zwar in sich konsistent ( bid kleiner als ask , Sortierung ist ebenfalls OK, also keine Möglichkeit den Fehler durch triviale Checks zu erkennen), bleibt ein paar Sekunden so falsch, und nach einigen Sekunden ist der Spuk vorbei. Kann mir vorerst helfen, indem ich Arbitragen von mehr als 1% Gewinn ignoriere. Kommt mir so vor, als ob ein Orderbuch angezeigt wird, das einige Stunden alt ist. |
12313123
|
|
|
|
Darkwinde
|
|
November 25, 2014, 09:57:26 AM |
|
Das kann jetzt mittlerweile echt nurnoch ein API Server Überlast Szenario sein. So unregelmäßig und an unterschiedlichen Stellen das kommt. Und wenn ich noch weitere identische Calls nur mit nem Delay absetze werden diese mit gleicher OrderID korrekt beantwortet. Ich schreibe später mal ein Script das permanent kauft, Status abfragt und Cancelt um das nachzuweisen. Bekommen die BTer Jungs ein nettes Ticket von mir Von mir bekommen die von Bter auch ein Ticket. Vor allem der BTC/CNY Markt ist dort zeitweise vermurkst. Zeitweise ein falsches Orderbuch, bis zu 5% daneben. Zwar in sich konsistent ( bid kleiner als ask , Sortierung ist ebenfalls OK, also keine Möglichkeit den Fehler durch triviale Checks zu erkennen), bleibt ein paar Sekunden so falsch, und nach einigen Sekunden ist der Spuk vorbei. Kann mir vorerst helfen, indem ich Arbitragen von mehr als 1% Gewinn ignoriere. Kommt mir so vor, als ob ein Orderbuch angezeigt wird, das einige Stunden alt ist. Scheint wohl irgendein Caching und/oder Publizierungsproblem auf Seiten von BTer zu sein, dass mir wirklich in die Suppe spuckt... Vielleicht kann/mag jemand das verifizieren. Abblauf: 1) Setzte eine Order in einen beliebigen Markt 2) Hol dir den Status der Order via "private/getorder" API 3) Cancel die Order Ergebnis:1) Wenn man innerhalb der ersten 10 Sekunden nach Erstellung der Order den Status abrufen möchte, bekommt man ein API Response Error "Invalid Order ID". Nach den 10 Sekunden ist die Order ID auf einmal bekannt und kann abgefragt werden. 2) Wenn man nicht innerhalb der ersten Minute nach der Erstellung der Order wieder den Status abfragt, "vergisst" die API ebenfalls wieder diese Order ID und bei der dann gestellten Anfrage bekommt man erstmalig wieder ein Invalid Order ID zurück. 3) Man kann den Umstand jetzt auf mehreren Ebenen begegnen. Ich habe mich für die Variante entschieden, dass nach einer Order nach 15 Sekunden ein Pseudo-Call abgesetzt wird, um den Cache für weitere Abfragen vorzubereiten. Die Frage die sich natürlich daraus ergibt, wenn die Latenz bereits beim einstellen einer Order so massiv ist, wie wird es dann wohl bei anderen Schnittstellen sein...  Wer es testen mag, einfach den API Key ($apiKey) und Secret ($apiSecret) von eurem Account verwenden und mit dem auskommentierten sleep Timer experimentieren. <?php
date_default_timezone_set('Europe/Berlin');
while(true)
{
$pair = "WDC_BTC";
$buyrice = 0.00001000;
$buyAmount = 50;
logging("/////////////////////////////");
logging("BUY ORDER");
$buyOrderID = buyOrder($pair, $buyrice, $buyAmount);
var_dump($buyOrderID);
// Change this parameter to find the sweet spot of the API response / caching time
//sleep(15);
logging("/////////////////////////////");
logging("INFO ORDER");
$info = statusOrder($buyOrderID["order_id"]);
var_dump($info);
logging("/////////////////////////////");
logging("CANCEL ORDER");
$cancel = cancelOrder($buyOrderID["order_id"]);
var_dump($cancel);
logging("/////////////////////////////");
logging("FINISHED");
logging("/////////////////////////////");
sleep(20);
}
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
function query($path, array $req = array())
{
$api_url = "https://bter.com/api/1/";
$apiKey = "";
$apiSecret = "";
// Prevent API from overload
usleep(300000);
// generate a nonce to avoid problems with 32bits systems
$mt = explode(' ', microtime());
$req['nonce'] = $mt[1].substr($mt[0], 2, 6);
// generate the POST data string
$post_data = http_build_query($req, '', '&');
$sign = hash_hmac('sha512', $post_data, $apiSecret);
// generate the extra headers
$headers = array(
'KEY: ' . $apiKey,
'SIGN: ' . $sign,
);
//!!! please set Content-Type to application/x-www-form-urlencoded if it's not the default value
// curl handle (initialize if required)
static $ch = null;
if (is_null($ch)) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_USERAGENT,
'Mozilla/4.0 (compatible; Bter PHP bot; '.php_uname('a').'; PHP/'.phpversion().')'
);
}
curl_setopt($ch, CURLOPT_URL, $api_url . $path);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
// run the query
// run the query
$error = null;
for ($i = 0; $i < 5; $i++)
{
try
{
$res = curl_exec($ch);
}
catch (Exception $ex)
{
$error = "[BTER] Private API CALL error: " . print_r($ex->getMessage(), true);
logging($error, true);
sleep(1);
continue;
}
if ($res === false)
{
$error = "[BTER] Could not get reply: " . curl_error($ch);
logging($error);
continue;
}
$dec = json_decode($res, true);
//Debugging only
// var_dump($dec);
if (!$dec || $dec["result"] != "true" || (key_exists("msg", $dec) && $dec["msg"] != "Success"))
{
$error = "[BTER] Private API RESPONSE error: " . print_r($dec, true);
$info = " Method: " . print_r($path, true) . " / Parameter: " . print_r($req, true);
logging($error . "\n" . $info, true);
sleep(5);
continue;
}
else
return $dec;
}
}
function buyOrder($pair, $buyrice, $buyAmount)
{
return query('private/placeorder', array
(
'pair' => strtolower($pair),
'type' => 'buy',
'rate' => $buyrice,
'amount' => $buyAmount
)
);
}
function cancelOrder($orderID)
{
return query('private/cancelorder', array('order_id' => $orderID));
}
function statusOrder($orderID)
{
return query('private/getorder', array('order_id' => $orderID));
}
function logging($message)
{
echo date("H:i:s") . ": " . $message . "\n";
}
|
|
|
|
|
|
|
Darkwinde
|
|
November 25, 2014, 11:42:35 AM |
|
Bin ganz bei dir.... Cryptsy hat heute wieder 50 SAT2 von meinem Account abgezogen ^^ obwohl sie ja hoch und heilig versprochen haben der Bug sei gelöst. MUAHAHAHA mir hupe da dort eh nur Coins und BTC zum Testen im Wert von 0,01 BTC liegen. Die werde ich jetzta uch noch abziehen Schade drum, Cryptsy scheint wirklich langsam Richtung Gox zu maschieren... |
|
|
|
|
Darkwinde
|
|
November 25, 2014, 05:32:16 PM |
|
Also das "Pseudo Pollen" der API Schnittstelle scheint wirklich das einigermaßen zu tun. Seit 24 Stunden keine "Beschwerden" mehr. Testscript werde ich später nochmal dediziert laufen lassen und dann ein Ticket bei BTer eröffnen Erstversorgung meines Beta Testers war erstmal wichtiger als den Support zu nerven |
|
|
|
|
Darkwinde
|
|
December 03, 2014, 12:05:24 AM |
|
Also das "Pseudo Pollen" der API Schnittstelle scheint wirklich das einigermaßen zu tun. Seit 24 Stunden keine "Beschwerden" mehr. Testscript werde ich später nochmal dediziert laufen lassen und dann ein Ticket bei BTer eröffnen Erstversorgung meines Beta Testers war erstmal wichtiger als den Support zu nerven Bin bisher nicht mehr zum Testen gekommen  ob es wohl daran liegt, dass jetzt wohl alles unauffällig läuft  Das Pseudo Pollen hat bei mir wirklich viel bewirkt, wer also auch bei BTer ähnliches sieht kann gerne meinen Workaround frei nutzen! Ansonsten gibt es nicht viel Neues. Wie immer hält mich die Arbeit auf Trap und komme kaum zum Coden. Aktuell fixe ich nur die Bugs die mir mein Beta-Tester meldet und da ist der letzte auch schon bald 2 Wochen wieder her sprich ich muss mir mal wieder ein neues Ziel/Idee setzen um bis 4 Uhr nahcts zu Coden und mit Augenringen in die Firma zu torkeln Also her mit euren Ideen *FG* Wie läuft es bei euch anderen so? |
|
|
|
|
kalkulatorix (OP)
|
|
December 03, 2014, 11:02:00 PM |
|
Wie läuft es bei euch anderen so?
Wie bei Dir, viel zu wenig Zeit für die wirklich wichtigen Dinge.  Habe Deinen Ordertest angeschaut, bei mir ist das nötige Sleep - Delay sehr variabel, aber spätestens nach 300ms sehe ich sie. 20ms braucht es aber immer. Ich würde das Pollen mit ansteigenden Delays machen, sonst kommt BTer noch auf die Idee, dass eine DDoS Attake versucht wird, und setzt Deine IP auf eine Blacklist. Also nach dem BuyOrder erst einmal fix eingestellt warten, vielleicht so 40ms, und wenn dann nichts kommt wiederholt abfragen, in Fibonacci Abständen, als z.B. Sleeps von 10,10,20,30,50,80,..... zwischen den Polls einbauen. Musste aus gegebenen Anlass eine Sicherheit einbauen, vor 2 Wochen war das Orderbuch auf BTer zeitweise falsch, habe einen Gegencheck mit dem Ticker programmiert, das Orderbuch darf nur um die doppelte Spanne des Tickers abweichen, andernfalls nimmt der Bot ein Problem mit dem Orderbuch an. Seitdem ich das eingebaut habe, sind die Orderbuch Probleme von BTer nicht mehr aufgetreten. Ich frage den Ticker immer nur alle 15 Minuten ab, oder wenn das Orderbuch vom Ticker abweicht, dadurch verbraucht der Ticker nicht so viele API-Calls. Auch wenn ich den Check mit den Ticker aktuell nicht mehr brauche, bin ich doch über diese zusätzliche Sicherheit froh. Im Moment arbeite ich an einem HTML-Export, möchte die wichtigsten Daten des Bots am Webspace ablegen, damit ich den Bot auch einfach von unterwegs kontrollieren kann. |
12313123
|
|
|
|
Darkwinde
|
|
December 06, 2014, 07:19:57 PM |
|
Webinterface hab ich nebenher immer mitgezogen, da ich sonst immer wie wild in der DB rumeiern müsste. Nach dem 5 Mal nervt die Performance einfach über VPN in einen 16er DSL Endpunkt mit MySQL auf nem Raspberry PI . Dem Bot reicht es, dem User nicht Ich habe eh ein kleines Delay eingebaut als DDOS Protection aber dennoch komm ich ohne direkte Abfrage nach einer Order nicht zu einem konstanten Ergebnis. Solange es läuft lass ich erstmal so wie es ist. Was mich mehr stört ist aktuell das ich für Webinterface 3 Sprachen verwende... Java Script, HTML und PHP. Werde das aber nicht änder können wenn ich nicht eine gleichwertige freie Plotting Engine für PHP finde :/ |
|
|
|
|
kalkulatorix (OP)
|
|
December 06, 2014, 08:16:28 PM |
|
Plotting Engine? Mit so was darf ich gar nicht beginnen, sonst verbrauche ich zu viel Zeit mit Details. Ich möchte mir nur eine Info - Seite basteln, damit ich auf einen Blick sehen kann, was gerade los ist. Habe keinen Zugriff von außen auf den Bot geplant, ich kann ihm nur die Funds durch Orders mit Mondpreisen blockieren.
Das Problem mit veralteten Daten ist auf jeder Exchange, CEX.IO ist da am schnellsten. Ich mache immer 10 Sekunden Pause nach dem versenden von Orders, da ich alle Orders aus einer Arbitrage gleichzeitig sende, kann ich dem Bot die Pause gönnen.
|
12313123
|
|
|
|
Darkwinde
|
|
December 07, 2014, 03:56:25 AM |
|
Plotting Engine? Mit so was darf ich gar nicht beginnen, sonst verbrauche ich zu viel Zeit mit Details. Ich möchte mir nur eine Info - Seite basteln, damit ich auf einen Blick sehen kann, was gerade los ist. Habe keinen Zugriff von außen auf den Bot geplant, ich kann ihm nur die Funds durch Orders mit Mondpreisen blockieren.
Das Problem mit veralteten Daten ist auf jeder Exchange, CEX.IO ist da am schnellsten. Ich mache immer 10 Sekunden Pause nach dem versenden von Orders, da ich alle Orders aus einer Arbitrage gleichzeitig sende, kann ich dem Bot die Pause gönnen.
Auch du wirst noch dem SchiSchi verfallen junger Padawan http://www.flotcharts.org/Webinterface hat bei mir nur anzeigende Funktion, keine verändernde/eingreifende. Wäre mir auch einfach zu heikel den Bot einfach noch weiteren Einflüssen auszusetzen. Das Chaos der Exchanges reicht mir schon Veraltet sind die Daten ja bei BTer nicht, nur werden sie nicht sauber ausgeliefert. Bekomme jetzt sogar statt einer Fehlermeldung oder keiner Antwort ein TRUE zurück wenn ich von der API wissen möchte wie der Status meiner Order ist. Da soll mir noch einer sagen, dass die Kollegen dort wissen was sie tun Aber auch das werde ich noch behandeln und in eine saubere Meldung überführen. Die tatsache das da ein True zurück gibt ignoriert der Bot eh. Frei nach dem Motto: Das Schema was du mir anbietest ist nicht das was ich erwarte...also troll dich...ich frage gleich nochmal |
|
|
|
|
kalkulatorix (OP)
|
|
December 08, 2014, 12:11:56 PM |
|
Veraltet sind die Daten ja bei BTer nicht, nur werden sie nicht sauber ausgeliefert. Bekomme jetzt sogar statt einer Fehlermeldung oder keiner Antwort ein TRUE zurück wenn ich von der API wissen möchte wie der Status meiner Order ist. Da soll mir noch einer sagen, dass die Kollegen dort wissen was sie tun Aber auch das werde ich noch behandeln und in eine saubere Meldung überführen. Jetzt wird mir Einiges klar. Ich musste wegen der unpassenden Multithreads Implementation im PHP auf C# umsteigen. C# ist stark typisiert, deswegen funktioniert das json_encode/json_decode im C# anders, da muss für jede Response eine Klasse definiert werden, und die Response von der Exchange wird dann mit einem JavaScriptSerializer in das C# Konstrukt geschrieben. Wenn in der Klasse etwas ist, was nicht in der Response ist, gibt es eine Exception. Die Response darf allerdings auch nicht benötigte Informationen enthalten. Und ich habe sehr viele Exceptions, die ich mir bislang nicht erklären konnte, werde einmal aus Neugierde nachschauen, ob der Grund für die Exceptions unvollständige Responses sind. Habe das etwas unsauber gelöst, ein Exceptionhandler für Alles, da die Behandlung der Exceptions gleich ist: Response wird ignoriert, und beim Nächsten Mal klappt es hoffentlich. |
12313123
|
|
|
|
kalkulatorix (OP)
|
|
December 08, 2014, 08:51:04 PM |
|
Veraltet sind die Daten ja bei BTer nicht, nur werden sie nicht sauber ausgeliefert.
jetzt habe ich auch so ein Beispiel für eine vermurkste Order Response von BTer gefunden: {"id":"83334352","oid":"5771520","sell_type":"USD","buy_type":"LTC","sell_amount":"0.00000001","buy_amount":"0","pair":"ltc_usd","type":"buy","rate":false,"amount":"0.00000001","initial_rate":3.4877,"initial_amount":"0.0417","status":"open"}, Habe lange gesucht, habe leider viele offene Order im BTer. Mit dem Text der Exception war das aber nicht so schwer: ERROR in Open Orders: Connection:bter Error:Exception:False ist kein gültiger Wert für Double. Als Strafe für diesen Fehler musste BTer heute 4700 Open Order Abfragen für mich beantworten. |
12313123
|
|
|
|
Darkwinde
|
|
December 08, 2014, 11:31:34 PM |
|
Jaja und ich bin paranoid und sehe überall Rose Exceptions Jetzt ist natürlich spannend warum er dir was meldet und mir nicht. Hmmmm muss mal mein Handler prüfen. Danke für den Hinweis! Ansonsten war das Wochenende so ruhig, dass keine Trades stattgefunden haben. |
|
|
|
|
