Strona 1 z 2 12 OstatniOstatni
Pokaż wyniki 1 do 10 z 12

Temat: probsa o wyjasnienie TCP

  1. #1
    Zarejestrowany
    Aug 2007
    Skąd
    London
    Postów
    4

    Domyślnie probsa o wyjasnienie TCP

    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.

  2. #2
    Avatar ble34
    ble34 jest offline jestem bugiem
    Zarejestrowany
    Oct 2006
    Skąd
    krzesło
    Postów
    681

    Domyślnie

    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
    Ostatnio edytowane przez ble34 : 08-28-2007 - 18:57

  3. #3
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    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.
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  4. #4
    Zarejestrowany
    Aug 2007
    Skąd
    London
    Postów
    4

    Domyślnie

    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
    Ostatnio edytowane przez karolla : 08-28-2007 - 21:43

  5. #5
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    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.
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  6. #6
    Zarejestrowany
    Jul 2007
    Postów
    120

    Domyślnie

    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ś.

  7. #7
    Zarejestrowany
    Aug 2007
    Skąd
    London
    Postów
    4

    Domyślnie

    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

  8. #8
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    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?!'
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  9. #9
    Zarejestrowany
    Jan 2007
    Postów
    695

    Domyślnie

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

  10. #10
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    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.
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

Strona 1 z 2 12 OstatniOstatni

Podobne wątki

  1. tcp/ip, pakiety- pytanie
    By eoor in forum TCP/IP/Analiza/Badanie
    Odpowiedzi: 2
    Autor: 07-29-2007, 15:07
  2. analizator tcp/ip.....sprawdzony
    By ironwall in forum TCP/IP/Analiza/Badanie
    Odpowiedzi: 10
    Autor: 07-18-2007, 17:33
  3. Odpowiedzi: 1
    Autor: 07-01-2007, 20:44

Zasady Postowania

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •  
Subskrybuj