我的情況是：一個C++程序需要使用FIX協議與Java程序進行通信。FIX通信模型 - 消息傳遞或套接字
我的解決辦法： - 消息：C++程序發佈在FIX格式的文本哪個Java progrma可以消耗並用的quickfix/J解析。 - 套接字：在Java程序中設置FIX服務器，然後C++程序作爲客戶端可以連接到此套接字並使用quickfix將字節流寫入它。 Java程序使用quickfix/j來解析字節流。
我的問題： 1.是否有插座的解決方案，即，與和quickfix編碼的字節流，可以充分的quickfix/J解碼任何兼容性問題嗎？ 2.哪一個更好？缺點和優點。
在此先感謝。
FIX消息傳遞將是一個更簡單的解決方案，而不是實現套接字。在quickfix庫中已經嵌入了套接字通信。除非你做了非常不同的事情，否則重新實現是沒有用的。該引擎旨在解密FIX消息。如果您想修改庫的任何套接字通信，則可以更改庫本身。反正你有源代碼。
如果您嘗試實現套接字，您可能必須編寫套接字以將消息從C++分析到Java，反之亦然。
你有C++版本的quickfix庫。使用它作爲發起者將FIX消息發送到Java接受器。您可能不必擔心編寫一個C++服務器在字節流中發送FIX消息。讓底層圖書館做好溝通的工作，而不是你自己。
FIX可能更容易。但是，如果您選擇套接字，請確保將C++程序中的數據send/recv轉換爲/從網絡字節順序。 （參見參考文獻：htons(),htonl()ntohs()和ntohl()）。 Java總是使用網絡字節順序，所以你不必在那裏做任何轉換。
這不是多個體繫結構中的庫的問題。 Quickfix庫用戶不必擔心這一點。 – DumbCoder 2010-10-11 10:31:15
FIX是一種基於文本的協議，即您不必擔心字節順序。在線層面上，你所做的只是發送字符緩衝區。因此，如果您正在將C++程序寫入基於java（quickfixj）的客戶端/服務器，只要您遵守FIX協議，就沒有問題。再次
然後，DumbCoder上文所指出的，如果你不是太關心性能，你可以和quickfix使用（C++版本！）
非常感謝您的回覆，那麼我的擔心不是問題。 – lostinmoney 2010-10-11 14:36:29
修復引擎都寫在他們可以與對方交流的方式修復引擎。 雙方的語言或平臺無關緊要。 你可以簡單地使用JAVA版本和另一方的C++版本。
非常感謝您的回覆。我也更喜歡FIX消息。現在，C++程序將一個TextMessage發送到一個隊列，並且Java程序使用隊列中的消息，使用此文本消息構造一條消息。這是正確的解決方案嗎？ – lostinmoney 2010-10-11 14:35:42
如果您不想使用C++ quickfix庫，那很好。您的隊列是否設計用於多線程？ Quickfix負責同時發送消息的多個會話。排隊可能需要一段時間才能發送消息，FIX轉換速度較慢，所以如果您不關心使用隊列的延遲可能不是問題。發送TextMessage然後轉換是一個兩步過程。獲取您的數據並在第一時間創建FIX消息會更快，因爲您的最終目的只是創建FIX消息。 – DumbCoder 2010-10-11 14:46:46
我的隊列很好的設計用於多線程，我們在C++端使用quickfix，在Java端使用quiickfix/j。我的擔憂與你一樣，看來TextMessage解決方案是兩個步驟的過程，它是間接的。我想知道是否有用於quickfix或quickfix/j的內置消息機制？由於消息順序對我們非常重要，因此如果使用多個會話，是否存在順序問題？ – lostinmoney 2010-10-11 15:06:00