komunikacja między aplikacjami TCP

witam

mam kilka aplikacji, które muszą ze sobą się komunikować i przesyłać sobie dane w sieci lokalnej.
Aplikacje będą na rożnych komputerach (czasem kilka aplikacji na jednym kompie).
Dane będą przesyłane asynchronicznie.

zastanawiam się nad realizacją takiej struktury z wykorzystaniem protokołu TCP.

Czy wystarczy ze zrobię dwa porty (client i server) w każdej aplikacji do komunikacji z wszystkimi,
czy powinienem mieć oddzielne dwa porty dla każdej aplikacji, z która chce się łączyć?

Czy w przypadku nadawania w tym samym czasie, przez kilka aplikacji do jednego odbiorcy,
protokół zapewni dostarczenie wszystkich danych?

Prościej napisać serwer, który będzie zarządzał tymi aplikacjami (klientami). W przeciwnym wypadku aplikacja będzie skomplikowana (musi zawierać serwer i klienta), musisz znać dokładnie adresy IP klientów/serwerów, nie połączysz się z serwerem jeśli będzie za natem.

edit:
nie doczytałem, że działać to ma w sieci lokalnej. Może wykorzystaj adres rozgłoszeniowy sieci? Natomiast identyfikację aplikacji umieść w ramkach swojego protokołu.

wystarczy jeden stały port - dla serwera. Klient już sobie sam poradzi z ustaleniem numeru portu. Natomiast musisz mieć co najmniej dwa gniazda - jedno cały czas otwarte i nasłuchujące dla serwera oraz otwierane w razie konieczności dla klienta. Przy takim podejściu serwer nie będzie mógł nic przekazać do klienta dopóki ten się nie połączy (oczywista oczywistość :p). Jeśli wszystkie aplikacje są Twoje to zastanów się czy pomysł z jednym serwerem, zawsze na tym samym kompie nie byłby lepszym rozwiązaniem (w sieci lokalnej odpada problem publicznego IP)

komunikacja będzie się odbywać tylko miedzy dwoma aplikacjami na raz,
na zasadzie komunikatów np A->B, B->C, C->A, B->A.
Nie planuję sytuacji, w której będę wysyłał jeden komunikat do wielu składników.

Każdy składnik miałby jeden stale otwarty port nasłuchujący
i drugi otwierany w momencie wysyłania komunikatu.

Zakładałem że konfigurując każdy składnik, podawałbym ręcznie adresy IP i nr portów na których nasłuchują pozostałe składniki.

Czy taka struktura ma jakieś poważne błędy, lub sprawia uciążliwe problemy?

Zamiast gołego TCP polecam skorzystać z RPC (które wewnętrznie i tak używa TCP). Plus jest taki, że wysyłanie wiadomości wygląda jak zwykłe wywoływanie zdefiniowanych funkcji przy czym RPC supportuje wywołania synchroniczne i asynchroniczne, więc nie musisz tego klepać sam.