Niezbędne niezawodne/trwałe gniazda wychodzące, opcje?

Question

Mam aplikację Scala, która utrzymuje (lub próbuje) połączenia TCP z różnymi serwerami godzinami (prawdopodobnie> 24) na raz. Każdy serwer wysyła krótki, ~ 30-znakowy komunikat około dwa razy na sekundę. Komunikaty te są przekazywane do iteratee, gdzie są analizowane i ostatecznie kończą wprowadzanie zmian stanu do bazy danych.

Jeśli którekolwiek z tych połączeń z jakiegoś powodu nie powiedzie się, moja aplikacja musi nieustannie próbować nawiązać połączenie, dopóki nie określę inaczej. Wszelkie wiadomości zgubione są złe. Nie mam kontroli nad serwerami, z którymi się łączyłem lub używanymi protokołami.

Można sobie wyobrazić, że będzie ich aż 300 na raz. Brak dokładnie scenariusza wysokiego obciążenia, więc nie sądzę, że NIO jest potrzebny, chociaż może być miło mieć? Inne bity aplikacji są bardzo obciążone.

Szukam jakiegoś kontrolera gniazda/menedżera, który może utrzymywać te połączenia tak niezawodnie, jak to możliwe. Używam teraz własnego kontrolera blokowania, ale ponieważ nie mam doświadczenia z kodowaniem gniazd (i wszystkimi różnymi ustawieniami, opcjami, przekroczeniami czasu itp.), Wątpię, aby osiągnął najlepszy możliwy czas działania. Poza tym w pewnym momencie potrzebuję wsparcia SSL.

Czy NIO miałoby jakiekolwiek rzeczywiste korzyści?

Czy Netty będzie najlepszym wyborem? Widziałem przykład Uptime here i myślałem o jego powieleniu, ale będąc nowicjuszem w sieciach niskiego poziomu, nie byłem pewien, czy istnieją lepsze opcje.

Answer 1

Jednak jestem niepewny z najlepszych strategii dla zapewnienia jak kilka pakiety są tracone, jak to możliwe, i zakłada się, że będzie to „rozwiązać” problem w jednej bibliotece lub innym.

Yup. JMS jest przykładem.

Przypuszczam, że wiele z tego sprowadzałoby się do strategii zgadywania czasu oczekiwania? Zamknij i ponownie otwórz gniazdo zbyt wcześnie, aby stracić wszystkie pakiety podczas podróży.

To prawda. Takie podejście nie będzie niezawodne, zwłaszcza jeśli połączenia będą regularnie przechodzić w górę i w dół.

Rzeczywiste rozwiązanie polega na tym, że drugi koniec śledzi otrzymane informacje, a także powiadomi nadawcę, kiedy połączenie zostanie przywrócone. Jeśli nie da się tego zrobić, nie masz realnego sposobu kontrolowania, ile się zagubi. (Tak właśnie działają niezawodne usługi przesyłania wiadomości)

Nie mam kontroli nad serwerami, z którymi się łączę. Więc jeśli nie ma innego sposobu na dostosowanie JMS do ogólnego strumienia TCP, nie sądzę, że zadziała.

Yup. To samo dotyczy sytuacji, gdy próbujesz wdrożyć to ręcznie. Drugi koniec musi współpracować.

Sądzę, że można skonstruować coś, w którym uruchamia się (powiedzmy) punkt końcowy JMS na każdym z serwerów zdalnych, a punkt końcowy używa gniazd domeny UNIX lub pętli zwrotnej (tj. 127.0.0.1) do komunikowania się z serwerem. Ale wciąż masz potencjał do utraty wiadomości.