Wie ihr dem Blog entnehmen konntet, gibt es bei mir und den Systemen einiges an Veränderung.
Rein von der Systematik ist es ein sehr interessantes Thema, weil ich hab noch nie Systeme in Ihren Equity Highs abgedreht. Bisher hab ich das immer in DD Phasen gemacht. Bei einigen Systemen war die Entscheidung gut bei einigen schlecht. Summa Summarum wäre aber besser gewesen, ich hätte die Systeme einfach laufen lassen.
Anyway, im Nachhinein sind wir an den Börsen immer viel schlauer :D
Aber der Financial Meltdown bringt auch von Broker und Systemautomatisierung einiges an Veränderungen mit sich.
Aus diesem Grunde suche ich einen .net/java Entwickler, der mit dem schreiben von HS für div. Broker Erfahrung hat.
Folgende Eckpunkte kann ich vorab schon geben:
* Leider kann ich aus Due Diligence Gründen keine Ninja Trader verwenden.
* Angebunden muss auf alle Fälle IB Tws und J-Trader werden.
* Wenn jemand Erfahrung für die Eurex MIS mitbringt wäre das ein Bonus muss aber nicht sein.
* Vollständig freie Hand. Das System sollte von Grund auf neu entstehen, man muss also nicht in irgend welchen CodeLeichen rumwühlen.
* Aufgaben des Systems sollen primär das “durchreichen” von Orders und das Error Handling sein.
* Das System muss auf mehren Servern gleichzeitig laufen und sich untereinander abgleichen bzw die Aufgaben der anderen Systeme übernehmen wenn eines ausfällt.
* Es muss unter strengen NDA entwickelt werden.
* Aufwand ist ca. 60h Coding + 40h (Sonstiges – Besprechung, Planung, Testing, Error Handling)
* Mindestens 2 weitere Jahre bezahlten Support.
* Arbeitsort kann Heimoffice oder Ösiland sein.
* Soll mit 1.1.2009 in den Testbetrieb übernommen werden.
* Bezahlung je nach können € 150 – 200,- pro Stunde bzw Fixum fürs Projekt wenn schon bestehender Code verwendet werden kann.
Wer grundsätzlich Interesse oder weitere Fragen hat, bitte sendet mir eure Unterlagen an enterlong@gmail.com. Pflichtenheft kann ich aber nur an die engere Auswahl nach NDA Unterzeichnung weiter geben.
Na ob du das in 100 Stunden durchbringst, da bin ich mal gespannt.
Realistischer wären schon 100 Manntage als 100 Stunden, für so eine Neuwentwicklung von Grund auf.
Alleine ein ausgeklügelter Mechanismus wie sich die redundatenen Applikationen untereinander Nachrichten senden + Aktionen setzen würde schon ca. 50 Tage benötigen.
Dazu vielliecht ein grafischer/webbasierend. Administrations-Client, der die verschiedenen Applikationsserver für den Verbund konfigurierbar macht (hinzu-, wegschalten von einezelnen Servern, die die Redundanz generieren),
auch ganz gut ist sicher ein Statistik-Teil im Client, der die atuellen Infos, Details usw. zu den Systemen ausgibt.
Und dann noch ein wahrer Admin-Teil, zum Ein- Ausschalten der Systeme, und vielleicht überhaupt eine Upload-Möglichkeit, über die neue Systeme (in einer festgelegten Art/Sprache) in den Rechnerverbund gelangen, damit man sie dann in der Oberfläche aktivieren kann, und sie einfach losstarten.
Auch ganz gern haben manche zum Thema Statistiken immer wieder generierte Excel-Files. So eine Generierung/Downloadmöglichkeit könnte man auch in den Admin-Clienten einbinden.
Alles in Allem würde ich für diesen Teil namens Admin-Oberfläche mitsamt den Backends rund 120 Tage an Aufwand schätzen.
Ein weiterer Eckpfeiler neben Redundanz und der Oberfläche wäre die Bereitstellung einer API zur Anbindung an die verschiedenen APIs der Broker.
Umsetzen würde ich hierfür aber eine Art von generalisierter, applikationseigenen API, hinter der man die verschiedenen APIs der Broker einschiebt.
Dadurch wird man flexibel und unabhängig von verschiedenen Broker-Vorgaben. Ändern sich diese mal bzw. nutzt man später eine neue API eines Brokers, so sind an der Gesamtapplikation sowie an den Sytemen keine Änderungen vorzunehmen.
Denn die Systeme kommunizieren bei meiner Überlegung nur stets mit der generalisierten API der Gesamtapplikation in immer der selben Art und Weise. Wie eine Anforderung einer Tick-Subscription zB oder eine vom System abgesetzte Order dann tatsächlich für den Broker XY umzusetzen ist, darüber entscheidet die API der Gesamtapplikation, und reicht sie an die entsprechende API des Brokers weiter.
Für die API-Erstellung + Einbindung der gewünschen Broker-APIs in die Gesamt-API schätze ich optimistische 70 Tage.
Der letzte große Teil, der mir auf die Schnelle einfällt, wären die Systeme selbst. Ich würde diese als pro Server des verteilten Server-Verbundes eigenständig laufenden “Module”/(Applikationen?) vorsehen.
Darauf hinauslaufen wird dieser Punkt halt, dass man eine Schnittstelle zur Verfügung stellt, über die so ein eigenständiges System mit dem darüber liegenden “Container” am Server kommunizert, sowie auf ein paar Steuerungs-Mechanismen, die es zu überlegen gilt (ein System muss gestartet, gestoppt usw. werden können). Und zu guter letzt werdenm mMn ein paar Monitoring-Mechanismen zu überlegen sein. Damit das System vom Container aus rudimentär überwacht werden kann – denn sind Systeme eigenständige Binaries, können diese Blödsinn machen bzw. einfach abstürzen, und das ist es gut, zusätzlich zur API, über die das System mit dem Container kommuniziert eine Kontrollmöglichkeit in Richtung Container –> System zu haben.
Für den letzten Punkt schätze ich 60 Tagge.
Somit hätten wir:
Redundanz im Rechnerverbund: 50 Tage
Administrations-Client des Gesamt-Systems: 120 Tage
Allgem. API zur Einbindung verschiedenster Broker-APIs: 70 Tage
Container-Entwicklung, in welchen dann die eigentlichen – von anderer Hand entwickleten – Handelssyteme zur Ausführung gelegt werden können: 60 Tage
Macht unterm Strich somit 310 Tage. Bei 8 Stunden, die ein Tag hat, sind das 2.480 Stunden bzw. 1,5 Jahre bei 5 Tagen pro Woche und 40 Wochen pro Jahr.
Dem gegenüber stehen die im Blog-Beitrag genannten 100 Stunden ;)
Ich zumindest würde so eine Sache aus dieser Ecke kommend aufziehen. Und nein, mich interessiert das Projekt nicht. Das hier sind nur meine Gedanken, die mir dazu aufgekommen sind, deshabl der Beitrag auch als Antwort auf den Artikel. Vielleicht nutzen die Gedanken ja jemanden etwas.
Hallo Joesf
Danke für Dein Posting.
Da hast Du einige sehr gute Punkte genannt und man merkt das Du richtig Ahnung von dem Thema hast.
Das was ich suche ist aber keine Stand Alone Variante sondern es ist nur ein Teil des Ganzen. Zugehörige Elemente hab ich schon bzw werde ich sie selbst über die kommenden Wochen anpassen. Server stehen schon und es geht nur um die Meldungen die hin und her gesendet werden müssen. Hab ja die letzten 10 Jahre auch hi und da was getan :D. Es ändern sich jetzt nur die Broker Anbindungen und deshalb möchte ich einige Spagetticode Systeme austauschen.
Es geht nur darum, dass mir aktuell für alles die Zeit fehlt und deshalb möchte ich den beschriebenen Teil auslagern.
Denke schon dass es in 100 Stunden machbar ist aber ich kann mich auch irren. ;) We will see
Ich hab mich vorher bei meiner Antwort wohl etwas zu sehr auf den Punkt versteift, dass der zu erstellende Output von Grund auf neu zu erstellen ist, nicht aber ein Gesamtumfeld ;)
Die 100 Stunden können deshalb natürlich durchaus genau den Kern der Sache treffen.
Vielleicht mag ich ja wirklich ein wenig von verteilt laufenden Applikationen verstehen, die in einem Enterprise-Umfeld eingebettet sind – das ist schließlich meine Arbeit darüber zu wissen – was ich bis jetzt aber noch überhaupt nicht gemacht habe das sind Trading-Systeme.
Genau damit aber möchte ich mich aus Interesse beschäftigen, und so in einem Zeithorizont über die nächsten Jahre an die Sache – rein aus fachlicher bzw. Sicht des Tradings selbst, nicht die technische Seite; dazu hätte ich schon jetzt ein Bild – zumindest semi-professionell herangehen.
Vor ein paar Monaten habe ich mich dazu auch zu deinem tradersschool-Kurs angemeldet, um mich mal näher mit dem Thema Money- und Risk-Manaegment zu beschäftigen.
Irgendwann werde ich wohl wieder mehr Zeit haben, mich dem Thema Trading zu widmen, und dann stehen die Lektionen mit ihren Übungen gleich mal an erster Stelle der zu erledigenden Aufgaben ;)
Vielleicht können wir uns irgendwann im nächsten Jahr ja mal kurz austauschen, über ein paar interessante erlebte Eckpunkte, auf die wir jeweils beim Applikationsdesign oder dem von Systemen gestoßen sind.
Meine E-Mail hab ich dir zumindest zu diesem Kommentar nun mal da gelassen, damit ich mehr bin als nur ein Josef, der ich nicht bin ;)
Hallo zusammen,
ich weiß nicht, ob das jetzt hier reinpasst, aber warum wählt ihr .net bzw. Java? Liegt das an der Performance oder vielleicht an der API? Ich lese öfters, dass C bzw. C++ performanter ist. Da stellt sich dann die Frage, ob das bei der heutigen Rechenleistung noch eine Rolle sielt.
Was haltet ihr davon? Was sind die Kritierien für die Auswahl einer Programmiersprache für Handelssysteme? Welche verwendet ihr?
Lg mci
Das schöne an der .NET-Umgebung (Ich gehe jetzt einmal von 3.5 aus) ist, dass keine der oben genannten Sprachen ausgeschlossen wird. Solange ein .NET-Framework vorliegt (das setzt natürlich midenstens eine WinXP(Server 2003)-Umgebung voraus) können alle Sprchen verwendet werden (auch AJAX, ASP, Silverlight usw…).
Das sieht dann z.B. so aus, dass Fenster in C#, abgesetzte Webapplikationen in ASP und die reine TCP-Socket-Verbindung zum Server in ANSI-C geschrieben werden können. Die Server-Komponenten können (wenn keine Windows-Server) in reinem C-Code geschrieben werden, weil dort ja graphische Komponenten eher zweitrangig sind. Clientseitig ist der Zeitfaktor in der Tat Nebensache, da die APIs der Broker Verbindungen zur Handelsplatform meist ja nur auf dem selben Rechner anbieten (meist Windows). Wer die Anwendung trotzdem in C schrieben möchte, weil er schnelle Reaktionszeiten haben möchte, wird spätestens bei der Fensterprogrammierung in C aufgeben.
P.S.: Wer mit dem Joystick im 3D-Chart live scalpen möchte, programmiert unter .NET mit dem XNA-Framework ;)))
Obwohl ich eigentlich recht viel Wert auf UI und graphische Darstellung lege sehe ich das nicht ganz so wie mr_n, dass man in C bei der Fensterprogrammierung aufgeben muss. Ich selber habe das jedenfalls (noch) nicht gemacht – allerdings programmiere ich auch in C++. Mir gefällt einfach die Performance von C/C++ und was damit alles möglich ist. Sicherlich erfindet man rel. oft das Rad neu – aber das macht (zumindest mir) auch Spaß.
LG Daniel
Bei so einem System wie hier würde ich den Geschwindigkeitsunterschied zwischen C und den modernen Just-In-Time-Compilern wie Java und .Net für so marginal halten, dass man wohl keinen bemerken wird – sofern während des Betriebs überhaupt in messbarer Unterschied auftritt.
Ist die erzielbare Performance des Order-Routings zum Broker wirklich wichtig, würde ich mein Hauptaugenmerk auf die Netzwerk-Latenz zwischen eigenem Server und Server auf Seiten des Brokers Hand anlegen.
Im Gegensatz zu ein paar Takt-Zyklen, die ein flotter C-Code vielleicht einspart, sind netzwerkmäßig je nach Situation hingegen wirklich einige ms pro Anfrage an den Broker einzusparen. Das kann die Durchlaufzeit einer über die Broker-API abgesandten Message durch solche Optimierungen schon mal einen Bruchteil des vorherigen Wertes senken.
Aus Gründen der Modularität und auch der Wartbar- und Erweiterbarkeit würde ich persönlich eher zu einer Java-basierten Lösung tendieren. Im Vergleich zu einer schnell erstellbaren C-Lösung bringen die strengen und komplex wirkenden Architektur-Vorgaben zwar gerade zu Projektbeginn einen gewissen Mehraufwand, ab einer gewissen Projektgröße oder bei späteren Weiterentwicklungen in der Zukunft zeigen sich die Vorteile eines groß aufgezogenen Enterprise-Umfelds aber deutlich.
.Net ist wohl auch ein recht zeitgemäßer Ansatz. Da das gesamte Umfeld drum herum aber doch recht stark von Microsoft dominiert wird, wirds dafür wohl kein so großes Angebot an Frameworks und Komponenten der diversen Hersteller geben wird.
Auch nicht ganz unwichtig finde ich persönlich, dass Windows-Systeme als Server überhaupt erst seit einigen Jahren einigermaßen geeignet sind. Das ganz einfach wegen der Stabilität, die man dort früher nicht unbedingt immer bekommen hat. Und überhaupt ist die Windows-Welt noch recht jung, weshalb ich mich mit .Net nicht daran fesseln wollen würde.
Ich weiß zB von keiner großen Bank in Österreich, die ihre web-basierte Telebanking-Lösung auf .Net-Basis und in einem Windows-Umfeld betreibt. Zwar solls Ende der 90er zu den Anfangszeiten des Telebankings für Privat vereinzelt exotische Lösungen mit Windows NT Servern gegeben haben, davon ist man aber recht schnell wieder abgekommen ;)
Hallo,
danke für die vielen Infos. Meine Fragen bezogen sich auf das serverseitige Programmieren. Für mich stellt .net ein Problem dar, da es nicht sourcemäßig für Linux verfügbar ist. (Abgesehen von Mono und ähnlichem) Ich denke für die schwarze Welt stellt Java die beste Alternative dar. Auch denke ich, dass Josef mit der genannten Enterprise Struktur ein wichtigen Punkt anspricht, besonders wenn es um die Wartung und die Erweitbarkeit geht.
Danke nochmal für die Infos und Anregungnen. Diese technischen Fragestellungen kommen IMHO oft zu kurz. Natürlich lässt sich über Geschmack und präferiertes Werkzeug streiten, doch bringen verschiedene Sichtweisen immer neue Ideen für den eigenen Gebrauch.
Thx
Lg Mike
Hallo Daniel,
arbeite selbst gerade für meine Zwecke im selben Umfeld. Die Handelssysteme wurden in Investox erstellt und die Orderausführung (IB TWS) implementiere ich gerade in Java. Die ganze Gschicht ist halt nicht trivial, insbesondere die STOP-Orders fordern mich ganz schön ;)
Cheers
Hallo,
Ich würde gerne wissen, wie oft euch die TWS von IB schon abgestürzt ist. Wenn die TWS abstürzt bedeutet das ja auch, dass das eigene Tradingprogramm nocht mehr arbeiten kann, von daher ein wichtiges Problem. Diesen “Single Point of Failure” könnte man ja durch nutzung des CTCI (FIX) – Interfaces von IB eliminieren. Nutzt jemand von euch diese Schnittstelle oder ist das einfach den Aufwand (alles muss selber programmiert werden und keine quotes von IB) nicht wert?
Ich habe zwar kein Tradingsystem (bin noch diskretionär unterwegs), möchte aber eines programmieren (auf Sicht von meheren Jahren). Ich bin ja auch erst 20 Jahre jung ;-)
mfg Luaks
Hallo,
ich halte 100 Stunden Arbeit auch für zur wenig Zeit um das alles zu bewerkstelligen. Wie Josef schon aufgeschlüsselt hat, kosten Features wie verteiltes System recht viel Zeit.
Zur Zeit arbeite ich an einem ähnlichen Projekt auch in Java, da die Sprache mächtig genug ist und es sich schöner Programmieren lässt. Ich bin dort an die TWS angebunden, speichere Ticks, Orders etc. in einer Datenbank (schneller Zugriff) und mache mir ehr über die Performance der TWS Gedanken, als über die meines Programms.
Allerdings neige ich dazu, die Verteilung auf mehrere Rechner so zu lösen, dass alle “Spectator”-Rechner nur wissen was der derzeit Handelnde macht, und im Falle eines Ausfalls macht ein Specator dann weiter (indem er das Wissen aus der Datenbank ziehen kann). Das spaart mir Synchonisationsaufwand innerhalb des Systems selbst.
Desweiteren finde ich einen GUI im System auch nur bedingt wichtig/praktisch. Ich will Strategien starten, stopen und einen groben Status haben. Alle näheren Infos (Statistiken) halte ich über ein Webinterface, welches nur mit der Datenbank kommuniziert für weitaus sinnvoller, da solche Anwendungen doch gegen alle Fälle gesichert sein sollten und das erreicht man nicht, indem man die Anwendung unnötig aufbläht.
Zumindest ist die Redundanz zwischen den Rechner so (meiner Meinung nach) durchaus praktikabler und wesentlich weniger zeitaufwendig.
Durchreichen von Orders scheint mir je nach Parametern, die man bekommt kein Problem, die TWS API bietet ja alle Funktionen die man möchte.
Auch das Error-Handlich wird sicherlich nicht so ein riesiger Aufwand, da die TWS ja gerade mal ca. 100 Errors feuert und man viels ähnlich behandeln sollte.
Was ich nicht einzuschätzen vermag ist die Anbindung an diesen J-Trader, da ich ihn nicht kenne und ich kenne auch nicht die “Wunschanforderungen” an das Programm als verteiltes System.
MfG
Christoph
Hallo Christoph,
das klingt schon ganz gut. Wie sieht es mit der Aufteilung der Datenbank aus? Läuft etwa auf allen Servern eine Datenbank die sich mit den anderen synchronisiert, oder gibt es nur zentrale DB?
@all: Was für ein OS habt ihr auf den Servern laufen? Windows, Linux/ Unix? Welche DBs laufen bei euch? mySQL, Firebird, vielleicht Oracle? Und wieso sind das eurer Meinung nach die Richtigen?
Ich baue auf Gentoo Linux, da sehr zuverlässig, Pakete direkt kompiliert werden, perfekt an die Hardware anpassbar und dadurch sehr performant ist. Soll hier natürlich keine Werbung werden. Jedem das Seine.
Könnt ihr vielleicht gute Literatur bzw. Links für die Erstellung von HACs, und das Programmieren in dem Umfeld nennen.
Danke im vorraus.
Lg
Mike
Eine Datenbank auf nem Root-Server, die die wichtigstens Daten speichert. MySQL -> kostenlos.
Christoph
Hallo!
Eine kleine Frage, rein aus Neugier: Was spricht gegen NinjaTrader?
Es stimmt, dass NT ein Haufen notwendiger Features fehlt, aber andererseits kann man es bedingt durch die Architektur des Programms praktisch beliebig selbst erweitern (und das sogar verhältnismäßig einfach).
Ich selbst habe mir z.B. eine MATLAB-Anbindung (zur Verwendung von Neuronalen Netzen), Statisktik-Export in Excel usw. gebastelt. Was ich noch machen werde, ist eine eigene Datenbank, in der ich alle Trades speichern werde.
lg
Thomas