@socrates666: NIC z dekoderem FastFixa (przeciw ktoremu toczy sie proces patentowy i bedzie zastapiony w przeciagu kilku miesiecy) jest w stanie ponizej 3us dostarczyc zdekodowane dane do pamieci (DMA / PCIE Gen2). Samo dekodowanie Fastfixa w hw i book building zajmuja krocej niz 1us. Dlaczego nie przenisiesz kodu z javy do hardwaru? Jak duzy jest kod ktorym sie zajmujesz? Czy moze on dzialac na embedded Cpu jak Arm cortex A9?
Na kilkanaście adapterów rynkowych, z którymi miałem styczność tylko jeden korzysta z FastFIX. W kilku odpowiedziach pisałem już, że wszystko przesuwa się w stronę hardware'owych rozwiązań. Nie bierzesz pod uwagę faktu, że operatorzy rynku mają bardzo często kłopotliwą manierę rozszerzania FIXa o swoje własne tagi. Słyszałem od kolegi, że rozwiązanie hw, które ewoluowali rozłożyło się właśnie na takiej customizacji.
Zgadzam sie z tym co piszesz o Fix i rowniez o FastFixie i tagach. Przez to widzialem custom tagi, gdzie ludzie przesylali inty w stringach. Sam fastfix jest kiepski do zdekodowania w fpga bo pozwala na var length fields i generalnie trzeba go dekodowac sekwencyjnie. Napewno nie jest to protocol zapewniajacy performance a w sumie smiesznie bo teraz wszedzie 10Gbit i wiecej stad komu zalezy na kilku bajtach mniej w payload pakietu
Kod adaptera jest niewielki.
Nie za bardzo widzę sens odpalania javy z tym