2010-10-12 12 views
9

Przez "lokalny" rozumiem, że oba działają w tej samej podsieci, w większości przypadków w tym samym hoście/maszynie wirtualnej, dlatego niektóre standardowe międzyplatformowe mechanizmy RPC, takie jak SOAP, XML-RPC, CORBA itp. Wydają się niepotrzebne.Jakie są dobre alternatywy dla komunikacji między lokalnymi programami w języku C++ i Java?

Ładunek to głównie dane liczbowe (w większości tabelaryczne) z niewielką ilością metadanych (na przykład dostępne usługi danych, opis/typ danych itp.) Z C++ na język Java oraz zdarzenia konsoli/skryptów interfejsu użytkownika z języka Java do C++. Tak więc program C++ działa jak serwer, a program Java - klient.

Mogę wymienić kilka opcji (głównie z przeszukiwania tej wspaniałej witryny), ale nigdy nie widziałem ani jednego z nich w realnej sytuacji w trudnych warunkach, więc mam nadzieję, że ktoś, kto "tam był, zrobił to", może pouczaj mnie o zaletach i wadach opcji.

  1. wspólna pamięć
  2. rur, standardowe wejście/standardowe wyjście itp
  3. klienta struktura danych przez zwykłego gniazdka (UDP) (prawdopodobnie this question)
  4. wiadomości przez gniazda zwykłego może być buforem protokół pomocną, Thrift , JSON, itp (this answer, między innymi)
  5. Java RMI z C++ serwer RMI (this question)
  6. JNI (niektóre odpowiedzi w this question)

Jestem prawie pewien, że przegapiłem wiele opcji. Dziękuję wszystkim za pomoc!


Zmieniano: Zapomniałem wspomnieć, że wydajność nie jest głównym problemem, że nie oczekuje się, że przepustowość danych do być ogromny (serwer jest mocno bazy związany), ale byłoby to ważne, aby wiedzieć, czy stoi jedna opcja być znacznie szybszym lub wolniejszym. Na przykład, przypuszczam, że nic nie przebije pamięci współużytkowanej (jeśli zostanie to zrobione poprawnie).

Odpowiedz

4

Opcje 3 i 4 są stosowane w rzeczywistych sytuacjach w trudnych warunkach.

Opcje 1,2,6 nie docierają do innego hosta.

Opcja 5 jest prawdopodobnie zbyt kłopotliwa dla strony innej niż Java.

Poszedłbym z Opcją 4, ponieważ Opcja 3 jest zbyt niska (chyba, że ​​Wariant 4 okaże się zbyt wolny). Wybierz swój ulubiony, wieloplatformowy, lekki protokół przesyłania wiadomości spośród wymienionych przez ciebie. Wszystkie są "przetestowane w walce" i posiadają biblioteki dla większości języków.

+0

Dzięki! Jak już powiedziałem, te dwa programy najprawdopodobniej znajdują się na tym samym hoście, więc byłbym bardzo wdzięczny, gdybyś mógł rozwinąć także opcje tego samego hosta. Jeśli chodzi o protokoły komunikacyjne, wiem, że każdy ma swoje wady i zalety, ale czy masz ulubioną własną? –

+1

Jeśli chodzi o komunikację z tymi samymi hostami, w pierwszej kolejności skorzystam z Opcji 4, a następnie rozważę uczynienie jej bardziej złożoną, jeśli okaże się, że jest zbyt wolna. – Thilo

1

Wybrałbym opcję 4. Pominęłbym 5. 2 byłby niezgrabny.

Mówimy o przekazywaniu liczb jako zwykłego tekstu, tak?

+0

Nie, dlaczego? Na pewno chcę skorzystać na przykład z wariantu protobuf. –

+0

Przekazywanie zwykłego tekstu jest dużo łatwiejsze do debugowania i przetwarzania, ponieważ usuwa wszelkie dziwne problemy z formatem binarnym.Oczywiście tekst jest dużo większy niż binarny, ale mówisz, że twoja stopa transakcji będzie relatywnie niska. Przekazałbym tekst, który mogłem i tylko wróciłem do pliku binarnego, gdybym musiał. –

+0

dziwne problemy z formatem binarnym nie powinny stanowić problemu przy korzystaniu z ustalonego formatu przewodowego, takiego jak protobuf. – Thilo

Powiązane problemy