Przesyłanie danych poprzez TCP/IP

[rt90]

Witam,
Mam pytanie odnośnie sposobu przesyłania danych w aplikacjach typu klient-serwer wykorzystujących protokół TCP/IP. Jak klient może sprecyzować, gdzie dokładnie dane mają być przesłane do serwera, tzn. jeśli aplikacja serwera odbiera tylko dane poprzez bloki TCP Read, a klient wysyła dane poprzez bloki TCP Write, to jak można dokładnie ustalić, który blok TCP Read ma odebrać konkretne dane ? Czy jest możliwość, aby przypisać jakieś konkretne ID do danego bloku ?
Kolejne pytanie, jak można zrobić to, jeśli serwer jest napisany w LabVIEW ale klient jest w Javie ? Może ktoś zna sposób, aby w Javie wysłać dane do konkretnego bloku TCP Read w serwerze ? Problem u mnie polega na tym, że jeśli chce wysłać kilka danych, do różnych bloków TCP Read to dane te się mieszają, tak jakby wszystkie dane szły tym samym Streamem. Czy jest jakaś możliwość na rozdzielenie tych danych i przesyłanie ich w odpowiedniej kolejności ? Z góry dziękuję za każdą pomoc. Dodam tylko, że jeśli chodzi o LabVIEW to jestem początkujący.

[jogurt_owocowy]

jeśli aplikacja serwera odbiera tylko dane poprzez bloki TCP Read, a klient wysyła dane poprzez bloki TCP Write, to jak można dokładnie ustalić, który blok TCP Read ma odebrać konkretne dane ?

Możesz otworzyć kilka połączeń z różnymi numerami portów...

Czy jest jakaś możliwość na rozdzielenie tych danych i przesyłanie ich w odpowiedniej kolejności ?

... albo przesyłać dane za pośrednictwem jednego połączenia, doklejać do nich dodatkową informację o ich przeznaczeniu wewnątrz aplikacji i - po odczycie z TCP - przesłać je we właściwe miejsce za pomocą kolejki.
Jeśli chodzi o kolejność wysyłania/odbierania, to protokół TCP zapewnia Ci ją sam z siebie: bajty odczytywane przez TCP Read są odczytywane w takiej kolejności, w jakiej zostały wysłane.

[rt90]

Bardzo dziękuję za odpowiedź.
Jak to można zrobić w sytuacji takiej jak na obrazu w załączniku ? Tzn. pierwszy blok TCP Read oczekuje na wartość 4 bitową, następną oczekiwaną wartością będzie 1 bitowa dana. Czy jest możliwość zrobienia tak, abym mógł wysyłać tą konkretną 4 bitową daną dowolną ilość razy, a ona i tak zostanie odebrana przez pierwszy blok TCP Read ? Kiedy najpierw prześlę 4 bitową daną i chcę przesłać ją jeszcze raz zostaje błędnie przesłana, ponieważ oczekiwana wartość do przesłania powinna mieć 1bit. Wtedy VI głupieje. Jak mogę dojść do sytuacji kiedy będę przesyłał dane ile razy będę chciał, a odpowiednio 4 bitowa dana będzie odebrana przez pierwszy blok TCP Read a 1 bitowa dana przez drugi blok TCP Read, czy jest w ogóle taka możliwość ?
EDIT: Dodam jeszcze, że główny problem jest taki, że serwer jest zrobiony w LabVIEW ale klient jest w Javie. Wiem, że jeśli obie strony byłyby w LabVIEW to nie ma problemu, bo odpowiedni blok TCP Write zostanie odczytany przez odpowiedni blok TCP Read, natomiast w Javie tak nie jest. Dlatego moje pytanie jest odnośnie i LabVIEW i Javy, czy jest taka możliwość w jednym jak i w drugim środowisku zrobić taką komunikację ?

[jogurt_owocowy]

Jak mogę dojść do sytuacji kiedy (...) 4 bitowa dana będzie odebrana przez pierwszy blok TCP Read a 1 bitowa dana przez drugi blok TCP Read, czy jest w ogóle taka możliwość ?

Najmniejszą jednostką,jaką możesz odczytać za pomocą TCP Read jest 1 bajt, nie bit. W sytuacji, w której nadawca będzie wysyłał 4-bajtowe i 1-bajtowe dane na zmianę, program z Twojego obrazka będzie je poprawnie odczytywać.

Wiem, że (...) odpowiedni blok TCP Write zostanie odczytany przez odpowiedni blok TCP Read

Nie wiem, co dokładnie masz na myśli, ale chyba coś złego. Nie ma czegoś takiego jak "odpowiedniość" bloków TCP Write i TCP Read. Połączenie TCP jest zdefiniowane poprzez adres IP i numer portu (ustawiane w TCP Open albo TCP Listen). Od momentu zestawienia połączenia, nadawca zapisuje kolejne bajty, a odbiorca - w tej samej kolejności - je odczytuje. Możesz je odczytywać pojedynczą funkcją TCP Read w pętli, możesz użyć kilku funkcji jedna po drugiej (jak na obrazku) - to nie ma znaczenia. I nie ma też znaczenia, czy to LabVIEW, czy Java, czy cokolwiek innego.

[rt90]

Jeszcze raz dzięki za pomoc, trochę mi się rozjaśniło ale to chyba nie do końca to czego oczekuję.
W LabVIEW jest wszystko w porządku, jeśli zrobię tak, jak na rysunku. Załóżmy, że jako daną 4 bajtową będę chciał przesłać String 0001 lub 0000 lub 1111, a jako daną 1 bajtową po prostu 1 lub 0. Jeśli zrobię to w LabVIEW wszystko jest ok, w tym sensie, że jeśli najpierw prześlę 0001, ale potem będę chciał jeszcze raz przesłać daną 4 bajtową już inną, powiedzmy, że 1111 to serwer w LabVIEW wyświetli mi wartość 1111. I tak mogę do woli, wartości będą poprawnie wyświetlane, następnie dana 1 bajtowa, mogę przesłać 0, potem 1, potem znowu zero i w odpowiednim miejscu wyświetli mi się odpowiednia wartość 0 lub 1.
Inaczej jest jeśli to aplikacja w Javie wysyła. Jeśli najpierw wyślę daną 0001, potem nie mogę już wysłać np. 1111 - wyświetli się zupełnie inna wartość, tak, jakby przesunięta bitowo. Jeśli natomiast wysyłam po kolei, tzn. najpierw wartość 0001, potem 1, potem znowu 1111, następnie 0 - wtedy wartości wyświetlają się poprawnie. Wynika więc, że muszę przesyłać w określonym porządku - tak jak by serwer w LabVIEW najpierw oczekiwał danej 4 bajtowej, a następnie danej 1 bajtowej i tak w kółko. Nie mogę wysyłać najpierw do woli danej 4 bitowej, a dopiero potem 1 bajtowej tak jak to się dzieje kiedy aplikacja w LabVIEW wysyła i odbiera. Będą się źle wyświetlały (odpowiednio każda dana 4 bajtowa i 1 bajtowa mają odpowiednie okna do wyświetlania swoich wartości).
Dlaczego tak się dzieje ?

[jogurt_owocowy]

Inaczej jest jeśli to aplikacja w Javie wysyła. (...) Dlaczego tak się dzieje ?

Ciężko coś więcej powiedzieć, nie widząc Twojego kodu, ale najwyraźniej aplikacja w Javie wysyła dane w inny sposób, niż ta napisana w LabVIEW.

Wynika więc, że muszę przesyłać w określonym porządku

Tak. To jest podstawowa zasada, której musisz się trzymać.

[rt90]

Jeszcze raz dzięki. Problem faktycznie leżał w aplikacji w Javie, trochę inaczej wysyłała dane. Po stronie LabVIEW wszystko było jak najbardziej ok.