Snelste manier om een TXT file van Frankrijk naar Tokyo te krijgen (realtime)

[Argon]

Hallo,

Even mijn vraag/probleem schetsen:

Momenteel hebben we een VPS in Roubaix staan, op de server draaien enkele Python3 scripts die Tele-gram Channels uitleest. Het Python script slaat een nieuw inkomende Tele-gram bericht op in een TXT en vervolgens leest een Node script het TXT bestand uit, analyseert het bericht en koopt al dan niet een bepaalde munt aan via de Node Exchange Wrapper. Bovenstaande werkt dus perfect.

Wat we gemerkt hebben is dat de communicatie tussen de VPS (Roubaix) en de API van de Exchange(Tokyo) niet super vlot verloopt. Bij het plaatsen van een order zien we een doorlooptijd van 200 a 250ms. Dit komt natuurlijk door de afstand tussen beide servers.

Nu hebben we in Tokyo ook een VPS gedeployed. Als we daar de test doen met het plaatsen van een order krijgen we een doorlooptijd van +-50ms. Dus vanuit Tokyo winnen we ongeveer een 150 a 200ms. (ja, die 150 a 200ms kunnen een groot verschil uitmaken )

Nu komt het probleem: De reactietijd van Tele-gram in het Tokyo DC is stukken slechter dan het DC in Roubaix. Dus wat we winnen bij het plaatsen van een order op de Exchange, verliezen we volledig door de trage connectie van Tele-gram daar.


Wat heb ik geprobeerd:
- Het Tele-gram script draait in het Roubaix DC
- Bij het binnenkomen van een bericht slaat het Tele-gram script de tekst op in een TXT file
- Op de server in Tokyo heb ik via sshfs een folder gemapped vanaf de Roubaix server (dus Tokyo kan aan een fileshare over SSH naar Roubaix)
- Het script die het order op de Exchange koopt draait in het Tokyo DC en haalt dus op zijn beurt de data op van het TXT bestand. Dit vanuit Node met de FS (filesystem) package

Bovenstaande setup werkt ook zoals het hoort echter zitten we met een vertraging van 0.800 seconden tot 1 seconde bij het uitlezen van het TXT bestand. Ik vermoed dat de FS module niet de beste oplossing is om te gebruiken over een sshfs verbinding.

Dus bij deze de vraag: wie o wie heeft er nog een idee van hoe dit aan te pakken. Het is een hobby/probeersel, dus misschien zijn we wel dingen aan het proberen die gewoon niet haalbaar zijn. Uiteindelijk blijven we met de grote afstand zitten doe we moeten overbruggen. Maar misschien zijn er betere/snellere methodes (websocket vanuit Node naar een TXT bestand, continue stream op één of andere manier, ...) voorhanden dan wat we momenteel hebben getest.

Benieuwd naar jullie creativiteit

[8balljunkie]

Je kan beter werken met message brokers tussen verschillende applicaties, want je gebruikt verschillende technologieën door elkaar.
Python -> txt -> nodejs uw nodejs moet dan ook constant monitoren dat er een nieuw bestand is.

Je kan dan beter een message broker als middleware opzetten zoals Kafka, ActiveMQ, rabbitMQ,...
Deze schrijven ook naar een file weg, maar zijn sterk geoptimaliseerd voor high availability en performantie.

[Argon]

@8balljunkie: Het klopt dat we 2 verschillende talen gebruiken. Het uitlezen van Tele-gram is er later bijgekomen (en was het makkelijkste in Python) terwijl het volledige Exchange gebeuren reeds in Node was aangemaakt (we spreken over +1500 lijnen). Dus graag hadden we dit zo behouden.

Nu hebben we zelf de test gedaan en als beide scripts (Python & Node) op dezelfde VPS draaien hebben we een verlies van +-5ms bij het doorgeven van de info. Dus dit is niet het grootste probleem tussen Roubaix - Tokyo.

Ik lees eens verder over Kafka, ActiveMQ, rabbitMQ,..

Bedankt!

[raf1]

NodeJS Google Cloud deployen op asia-northeast1, dan draait je applicatie in Tokio: https://cloud.google.com/about/locations/japan/

[Argon]

Het Node script (dat het order plaatst op Exchange) draait reeds als test op een VPS in Tokio, dus daar zitten we reeds goed.

Het is het Python script (Tele-gram uitlezen) vanuit Tokyo die traag is vergeleken met hier (Belgie/Frankrijk/...)

[CCatalyst]

Je moet meer achtergrondinfo verzamelen. Is Telegram gewoon niet goed aanwezig in Japan, of is het een specifieke slechte peering met AWS TYO?

Uitzoeken waar de Telegram-server staat die het script in AWS TYO probeert te bereiken. Is dit ver weg of niet?

Is dit via IPv4 of IPv6? Telegram en AWS peering beide goed aan AS6939 op IPv6. Op IPv4 is de peering minder gemeenschappelijk.

Instance met betere performance dan een t2.micro proberen.

Datacenter in TYO zoeken, liefst aan dezelfde exchange van AWS, dat goede peering met AWS en Telegram heeft en dat als middleman gebruiken.

Indien Telegram sowieso hopeloos is in Japan, kan je een ander land als middleman proberen (hint: Singapore).

[Argon]

Je moet meer achtergrondinfo verzamelen. Is Telegram gewoon niet goed aanwezig in Japan, of is het een specifieke slechte peering met AWS TYO?

Uitzoeken waar de Telegram-server staat die het script in AWS TYO probeert te bereiken. Is dit ver weg of niet?

Tele-gram zit blijkbaar nogal ingewikkeld in elkaar. We maakten verbinding met een Belgisch en Spaans gsm nummer en kwamen op Tele-gram DC4 terecht. Als we het script laten lopen in Tokyo geforceerd naar DC5 (Singapore) dan krijgen we het volgende:

Code: Selecteer alles

Please enter your phone (or bot token): +3xxxxxx
02-07 13:44 INFO     Phone migrated to 4
02-07 13:44 INFO     Reconnecting to new data center 4
02-07 13:44 INFO     Disconnecting from 91.108.56.122:443/TcpFull...
02-07 13:44 INFO     Disconnection from 91.108.56.122:443/TcpFull complete!
02-07 13:44 INFO     Connecting to 149.154.167.92:443/TcpFull...
02-07 13:44 INFO     Connection to 149.154.167.92:443/TcpFull complete!

Dus 91.108.56.122 is het Singapore Tele-gram DC, maar die verwijst ons onmiddellijk terug door naar 149.154.167.92 (UK) zonder dat we er enige controle over hebben. Kijkt Tele-gram enkel naar het gsm nummer om zo de locatie te bepalen, waardoor we terug connecteren naar de EU? Geen idee van momenteel...

Is dit via IPv4 of IPv6? Telegram en AWS peering beide goed aan AS6939 op IPv6. Op IPv4 is de peering minder gemeenschappelijk.

Dit is over IPv4. VPS in Roubaix is van Fusa (geen idee of IPv6 mogelijk is in onze huidige config) en ook geen idee van of dit mogelijk is met een t2.micro. Ik zou dit even verder moeten uitzoeken. Wat bedoel je net met "Tele-gram en AWS peering beide goed aan AS6939 op Ipv6"?

Instance met betere performance dan een t2.micro proberen.

Hadden we ook graag getest maar het is niet mogelijk om een andere instance te huren voor 1 maand bvb. Als we iets hoger willen gaan lijkt het altijd onmiddellijk een jaarabonnement te zijn die rond de $200 draait. Dus mochten we zeker zijn dat het lukt dan doen we het omiddellijk
Het enige die er trouwens op draait is het node script, dus CPU en Memory zijn zeker geen probleem. Als ik een speedtest doe dan halen we resultaten van 700mbps up and down. Nu het is vooral de latency die telt vermoed ik in dit geval...

Datacenter in TYO zoeken, liefst aan dezelfde exchange van AWS, dat goede peering met AWS en Telegram heeft en dat als middleman gebruiken.

Dit is zoeken naar een speld in een hooiberg vermoed ik? Ze zullen waarschijnlijk wel bestaan, maar hoe begin je daar achter te zoeken?

Indien Telegram sowieso hopeloos is in Japan, kan je een ander land als middleman proberen.

Dit hebben we momenteel ook in ons achterhoofd. Maar graag bewandelen we toch nog even dit pad

Bedankt !

[ubremoved_539]

Ik denk dat je gewoon realistisch moet blijven... Frankrijk en Tokyo liggen nu eenmaal aan de andere kant van de wereld.

[7zp]

Uw verhaal komt mij persoonlijk bekend voor waar ik mij een jaar geleden mee bezig hield. Arbitrage tussen meerdere exchanges? ML op basis van CNN regression predictie? "Hypertrading"?

Ik ga héél cru zijn maar ik hoop dat ge hier uit leert, en wat ik u nu al kan zeggen, ge zijt zéér telaat, crypto is aan het sterven, nog volatieler dan het was (het kleine beetje geld dat ge maakt kan ineens verdwijnen 5 minuten later), marges worden kleiner en kleiner, en ik hoop echt dat ge op veilige marges werkt. De tijd die ik de laatste maanden in mijn project stak kon ik waarschijnlijk meer verdienen om bij een bank, software bedrijf, als freelancer ML/AI zelf te gaan werken (nu niet dat ik enige academische kwalificaties heb om voor te leggen, en degelijk te solliciteren voor zulke jobs, maar ik wil een punt maken).

Tuurlijk loopt alles "traag", héél uw proces is alles behalve time critical, ge gaat nooit winnen op uw manier:
- Snelle software hebt ge gewoon niet met python of javascript, tuurlijk duurt het 1 seconden om een TXT bestand te analyseren. Herschrijf alles in Go of Rust, en als ge er de laatste 0.2% er wil uitpersen ga dan voor pure C of C++. Bekijk lectures van Andrei Alexandrescu over software optimalisatie (kunt ge door trekken op alle talen).

- Gebruik geen third party libraries (das een plaag van traagheid in de python en js community), maar gebruik de STD libraries van uw taal naar keuze, is een beetje meer werk, maar da krijgt ge terug in milliseconden.

- Ik hoop trouwens niet dat uw TXTs er zo uitzien "KOOP:X:XXXX" per lijn (string manipulatie). Pers alles wat ge kunt zo klein mogelijk. En probeer data dat gerelateerd is aan elkaar in 8 bytes te steken. MMX instructies zullen het maximale uit uw CPU halen.

- Waarom (gratis) thid party kanalen gebruiken voor communicatie tussen uw applicaties (Telegram? uw vps-> 50 verschillende tussenstops van telegram zelf-> uw andere VPS?), Encryptie? Zorg dat uw applicaties een Point-to-Point UDP(! niet de tragere TCP) verbinding heeft en smijt er een TLS laag boven op (zelfs dat hoeft niet, niet denken dat er iemand met uw data gaat lopen + enkele nanoseconden dat ge uw server bespaard).

- Met TXT files werken? Memory -> disk -> Memory? Hou alles gewoon in memory

- Time shared VPS? Neen huur volledige dedicated servers, waarvan ge zeker zijt dat uw CPU 100% scheduled is aan U en niet 200 andere containers.

- Huur deze servers zo dicht mogelijk bij de exchanges zelf, grote banken zetten hun servers ook pal naast Wallstreet, en niet in hun kantoren kilometers verder. En doe dit voor elke exchange, ga voor sub 10ms voor elke exchange.

- Contacteer de exchanges en zie of ge kunt betalen voor VERSE data, de API requests die ze publiek maken zijn ook maar cached versies van xx milliseconden geleden.

- Ik hoop dat ge niet op louche exchanges zit

Als ge diepere vragen hebt, stel ze maar.

[CCatalyst]

Ik veronderstel dat het niet anders kan dan met interpretatiescripts in Python en NodeJS (wellicht omwille van dat Telegram-gedoe), want anders snap ik niet dat OP zich zorgen maakt over latencies tussen datacenters, hoewel dat in theorie natuurlijk nooit 100% waar zal zijn, maar wellicht veel meer werk om in C of C++ te schrijven.

Maar indien niet dan idd overschot van gelijk. Ik heb zelf iets gelijkaardigs (niet voor crypto) en dat is een volledig geoptimaliseerd C programma dat over een IPIP tunnel communiceert met een ander C programma aan de andere kant van de oceaan, beiden in datacenters aan de Level 3 backbone, waarmee ik zelfs met die tussenstappen gevoelig sneller in de VS zit dan gewoon native Telenet routing.

Dit is over IPv4. VPS in Roubaix is van Fusa (geen idee of IPv6 mogelijk is in onze huidige config) en ook geen idee van of dit mogelijk is met een t2.micro. Ik zou dit even verder moeten uitzoeken. Wat bedoel je net met "Tele-gram en AWS peering beide goed aan AS6939 op Ipv6"?

Volgens HE gebruiken zowel Telegram als AWS peering van Hurricane Electric AS6939 voor een redelijk deel van hun IPv6 verkeer, waardoor het zou kunnen dat het sneller loopt via die weg dan via IPv4 waar de peering minder duidelijk gemeenschappelijk is en de data mogelijks meer tussenstappen moet maken.

Ik zou het iig proberen als het mogelijk is, denk wel dat alles van AWS nu IPv6 ondersteunt.

Het kan ook omgekeerd, dat IPv4 sneller is. Zie deze recente topic als praktijkvoorbeeld: http://userbase.be/forum/viewtopic.php?f=44&t=54571

Hadden we ook graag getest maar het is niet mogelijk om een andere instance te huren voor 1 maand bvb.

1 maand? Test gewoon met een instance On Demand ipv een Reserved.

Dit is zoeken naar een speld in een hooiberg vermoed ik? Ze zullen waarschijnlijk wel bestaan, maar hoe begin je daar achter te zoeken?

Lang lang zoeken en zoveel mogelijk gebruik maken van Looking Glasses als ze bestaan. Heb het ook al moeten doen.

Dit hebben we momenteel ook in ons achterhoofd. Maar graag bewandelen we toch nog even dit pad

Singapore is het eerste dat ik zou proberen.

[ubremoved_2964]

Wie is hier allemaal met hi-speed trading bezig op userbase?

[7zp]

Het jeukt nu toch wel een beetje om alles eens terug op te starten