probsa o wyjasnienie TCP

[karolla]

Witam,
od razu przepraszam za brak polskich czcionek.

Pomimo przejrzenia wielu informacji na temat TCP/IP jakos nie moge dojsc do ladu z tym wszystkim. Za duzo informacji w google
Mam stworzone takie polaczenie server-client w LabView i musze go przerobic na C++. Wszystko byloby ok gdyby nie jeden maly problem.
Server ma zdefiniowane 2 porty 4500 i 4501. Z tego co rozumiem to powinien nasluchiwac na 4500 i odpowiadac na 4501, ale widze, ze port 4501 jest jako listener. Hmm i tu cos mi neurony w glowie nie przewodza.
Client wysyla wiadomosc na 4500 porcie. Zatem po co jest ten port 4501?
Wiem ze to pewnie banalne pytanie i moze zbyt chaotyczne, ale gdyby ktos zechcial mi to wyjasnic bylabym wdzieczna.

[ble34]

znaczy masz napisać aplikacjie klijent serwer w c
?
co ona ma robić tylko wysyłac i odysłac dane
czy jakies konkrety
tez miałem z tym problemyy
właściewie z programowaniem socketów
wkórwaiące nazwy funkcji
ale to niejest takie skomplikowane
zabierz się do tego własnie od tej strony (czyli proste pisanie klijent serwer a potem to rozbudowywuj albo rozudowuj albo robudowywój niewiem ) jesli oczywiście niemasz narzuuconych jakiś sztywnych zasad
al enajpier w wyjaśnie oco dokładnie chodzi

[TQM]

Ja probowalem sie podpiac do LabView aby zbierac parametry z bioreaktora ale w pewnym momencie odpuscilem i zmienilem nieco temat badan aby uproscic sobie zycie.

Niewiele juz z LabView pamietam ale interfejs sieciowy jest dosc mocno zalezny od tego jak calosc polaczyles. O ile pamietam do LabView mozna kupic moduly pomiarowe gadajace juz same w sobie TCP/IP (nie jestem pewien), ale na pewno jak juz masz calosc polaczona do modulu kontrolnego to LabView wystawia wlasnie TCP/IP aby inne aplikacje mogly ssac dane z czujnikow po TCP/IP oraz o ile pamietam mogly kontrolowac przebieg procesu.

Jesli mnie pamiec nie myli, jeden port bylby do czytania danych z LabView, drugi do wstrzykiwania danych do LabView, czyli odpowiednio definiujac bramki moglbys poprzez TCP/IP uruchamiac np. pompy przy bioreaktorze. W tym momencie oba porty beda jako listener - jeden bedzie sluzyl do odczytywania danych przez Twoja aplikacje, drugi do modyfikowania parametrow procesu (np. podglad procesu przez WWW i jego modyfikacja np. z poziomu telefonu komorkowego przez interfejs WAP) - to DA SIE ZROBIC!

Specyfikacja protokolu jest w dokumentacji LabView a to gdzie i co jaki port robi chyba (ale tylko CHYBA) ustawia sie w schemacie procesu - TCP/IP bedzie tam widniec jako urzadzenie chyba.

Wybacz tyle 'chyba' i 'byc moze', ale ostatnio pracowalem z LabView 3-4 lata temu i to na juz wtedy niezbyt mlodej wersji - na pewno sporo sie zmienilo...

Swoja droga, napisz cos wiecej o projekcie ktory prowadzisz, moze bede w stanie cos wiecej doradzic.

P.S.
Wlasnie zamowilem katalog Cole-Parmer - szukam termometrow (datalogger'ow raczej) do zbierania parametrow z moich zdalnych serwerowni.

[karolla]

W labview jest modul odpowiadajacy TCP/IP ale mamy problem (chyba) z bufforem. Zatem chcielismy caly modul TCP/IP zamienic na biblioteke dll (co oczywiscie jest mozliwe z labview).
Co do samego projektu:
Jest to zwykle polaczenie server-client do przesylania pakietow. Testujemy modemy na tym. Wysylamy pakiety do clienta, pozniej client odsyla ta sama wiadomosc i patrzymy jaka jest roznica, jakie pakiety pobubilismy.
Niby wszystko bylo jasne do czasu jak zorientowalam sie, ze jest port 4501 ewidentnie to port listener (tak jest zdeklarowany w labview), ale jak puszczam aplikacje i sprawdzam na cmd:netstat -an to widze ze server slucha na 4500.
I teraz juz sie pogubilam.
Dodam dla przedmowcy, ze jestem dziewczyna taki tam maly szczegol
pozdrawiam

[TQM]

Przepraszam mea culpa...

Odpisujac na ciekawy temat nawet nie sprawdzam kto go napisal (uuuups!) tylko odpowiadam najlepiej jak umiem jednak nie mialem zamiaru urazic - przepraszam.

Co do pochodzenia portu 4500 to nie jestem pewien. W konfiguracji ktora ja sprawdzalem (bioreaktor do biologicznego oczyszczania sciekow mieszana kultura bakterii) mialem na jednym porcie czytanie wynikow/parametrow procesu, na drugim mialem mozliwosc wysylania polecen - choc do konca tego nie uruchomilem. Nie zauwazylem jednak aby jakies inne porty sluchaly w aplikacji.

[r_jaro]

A więc to jest tak - oczywiście chodzi tylko o c i c++. Aplikacja klient serwer musi posiadać przynajmniej jeden port. W twoim programie masz 2 jak wspominasz - 4500 oraz 4501. Po co - a no po to a żeby sobie ułatwić komunikacje - lub też utrudnić; w zależności o co biega.
Serwer - on pracuje na porcie i czeka - po co- a no po to żebyś ty się z nim połączyła. Funkcja Accept - jeśli się łączysz o funkcja ta albo zezwoli na połączenie - tak jest w 99.9% przypadków lub też nie. jeśli już jesteś połączona (klient z serwerem) to klient lub serwer może wysyłać i odbierać wiadomości (funkcje send i recv).
Jeśli klient wykonuje send to serwer wykonuje recv (proste klient wysyła to serwer odbiera). I tak o to wygląda komunikacja na jednym porcie. teraz dlaczego w netstat -abno masz tylko port 4500 - a nie ma 4501 - bo ten port nie jest aktywny. I po co to wszystko - najlepiej wytłumaczyć na przesyłaniu plików:
Wysyłasz na porcie 4500 żądanie do serwera - przyślij mi plik c:/plik.exe to ty wysyłasz ten plik na porcie 4501 i klient jeśli zacznie cokolwiek odbierać na porcie 4501 to zacznie wszystko zapisywać do pliku. Gdy serwer zakończy przesyłanie pliku wtedy możesz na porcie 4500 wysłać komende - 100% przesłano - klient będzie wiedział że może zamknąć wtedy plik. A i taka uwaga - jeśli serwer wysyła na porcie 4500 to klient odbiera na porcie 4500. A i pamiętaj - jeśli się łączysz z serwerem a klient posiada kilka portów to wtedy każdy port musisz połączyć - w przeciwnym wypadku połączenie będzie ale tylko na portach które połączyłaś.

[karolla]

Witam,
bardzo dziekuje za cenne uwagi. Jeszcze raz wszystko sprawdzilam i wynika, ze mam do czynienia z taka sytuacja:
Mam 2 porty oba sluchaja jak wlaczam client oba sa ESTABLISHED. I dobrze
Jesli klient wysyla info z 4500 wowczas server odpowiada na 4501.
Zatem jest mozliwa komunikacja dwukierunkowa w tym samym czasie. Client wysyla na 4500 a server odp na 4501.
Ale zastanawiam sie, czy nie lepiej skonfigurowac to tak jak tryb aktywny z ftp. Czyli komendy przesylac na porcie 4500 a dane na 4501. Ta druga opcja jest blizsza wersji LabView

[TQM]

Ja bym zostawil jak jest - mial 2 porty - jeden podpinasz do sterowania, drugi do czytania odpowiedzi - daje Ci to komunikacje dwukierunkowa, mozliwe ze nawet asynchroniczna. Pytanie czy potrzebujesz takiej konfiguracji.

Moja rada - wybierz to co jest najprostsze do zrobienia ale nie prostsze... zostaw nieco marginesu na dalszy rozwoj i dobrze to sobie udokumentuj (dokumentacja to podstawa) bo pozniej zginiesz w gaszczu schematow rysowanych na serwetkach ktore pozostaly po pizzy zjedzonej w biurze zamiast w domu podczas dlugich nocy gdy czlowiek sie zastanawia 'o co mi wtedy chodzilo?!'

[northdakota]

TQM doświadczenie?
Też cos wiem o papierach... mimo tylko 15 lat... Skarbnikiem jestem...;/

[TQM]

Zebys wiedzial ze doswiadczenie... przejalem tutaj w firmie ogromny system, ktory rosl sobie w sposob organiczny przez ostatnie 6 lat... bajzel w kodzie, zero dokumentacji - jak z Denisem znalezlismy linijke komentarza w kodzie to poszlismy na lunch (a bylo to kolo 10 rano) i wrocilismy tylko po nasze rzeczy okolo 18... pijani jak swinie

Majac system przetwarzajacy setki transakcji finansowych na sekunde, nie majacy dokumentacji, gdzie jeden z autorow opuscil firme a drugiego w kolko nie ma... koszmar!!!

To samo dotyczy jakiejkolwiek bardziej technicznej dokumentacji.

- Wiesz od czego jest ten kabel?
- Nie mam pojecia...
- To co robimy?
- To co zawsze - odlacz i zobaczymy kto przyjdzie sie poskarzyc!

Zlitujcie sie i robcie dokumentacje do swoich programow My teraz mamy wszystko udokumentowane... a na ile tylko czas pozwala dorabiamy dokumentacje do starych aplikacji.