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

Temat: Połączenie TCP/IP

  1. #1

    Domyślnie Połączenie TCP/IP

    Witam!

    Mam pytanie odnośnie połączenia TCP/IP, jak wiadomo TCP/IP jest połączeniem takim bezpiecznym jeżeli chodzi o przesyłanie... bo jest pewność że żaden pakiet nie zginie i dotrze w odpowiedniej kolejności. Ale czy tak jest zawsze? Nigdy nie ma przypadków że jakiś pakiet nie dotrze? Zawsze mogę sprawdzać ilość odebranych danych i porównywać z ilością która powinna być. Nie jestem tylko pewny czy TCP/IP samo w sobie nie ma czegoś takiego jak potwierdzenie o dostarczeniu/niedostarczeniu pakietu...
    Zastanawiam się czy lepiej wysłać 1000 znaków przez jedno wywołanie send, czy też wysyłać po 100 znaków.
    Ostatnio edytowane przez TDM : 09-15-2009 - 20:07

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

    Domyślnie

    szczerze mowiac nie ma to znaczenia... Ty programujesz warstwe aplikacji, system operacyjny obsluguje pozostale 6 nizszych warstw modelu... wiec masz podac do systemu dane wg formatu jaki Tobie odpowiada (wielkosc pakietu itd) a on to sobie sam potnie jak trzeba a odbiorca posklada...

    TCP numeruje pakiety, potwierdza odebranie kolejnych pakietow (np wysylam 6 pakietow po NNNN bajtow i czekam na potwierdzenie odbioru). Dzieki temu ze sa numerowane odbiorca wie w jakiej kolejnosci ma je poskladac. Jesli pakiet jest gdzies wycinany po drodze najczesciej przychodzi ICMP z odpowiednim kodem o nadawca juz wie co sie stalo i dlaczego pakiet nie dotarl. Nie musisz sie wiec o to martwic - o to zadba stos TCP/IP w Twoim systemie operacyjnym. Idea warstw w modelu OSI jest taka, ze mozna kazda warstwe wymienic niezaleznie bez dotykania w ogole pozostalych warstw (IPv6 to jedynie zmiana jednej warstwy, nie calego stosu).

    Poza tym... jest takie cos jak MTU i to moze dodatkowo doprowadzic do fragmentacji pakietu... wiec jak dasz pakiet 1kB to moze on zostac pociety na mniejsze przez OS i nawet o tym nie bedziesz wiedzial. Na prawde to nie jest wielki problem i nie musisz sie martwic o reczne skladanie pakietow - niech OS zrobi to za Ciebie, unikniesz bledow we wlasnej implementacji. Jako autor aplikacji mozesz co najwyzej dodac jakas sume kontrolna do zawartosci pakietu itp aby miec pewnosc ze dane sa poprawnie przeslane albo uzyc jakiegos VPNa i on zrobi to za Ciebie. Trzeba ulatwiac sobie zycie
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  3. #3

    Domyślnie

    send() wysyla blizej nie okreslona liczbe danych.
    musisz robic send poki nie wyslesz czlego bufora, nie istotne czy raz, czy 10k razy.

    tcp z zalozenia zapewnia prawidlowy transfer, ale tylko z zalozenia. Moge w tej chwili wymyslec 3 bugi, ktorych nie chce mi sie sprawdzac.

  4. #4

    Domyślnie

    Cytat Napisał rax666 Zobacz post
    send() wysyla blizej nie okreslona liczbe danych.
    tcp z zalozenia zapewnia prawidlowy transfer, ale tylko z zalozenia. Moge w tej chwili wymyslec 3 bugi, ktorych nie chce mi sie sprawdzac.
    Mógł byś je wymienić ?

  5. #5

    Domyślnie

    1. overflow numeru sekwencji
    2. kolizja checksumy
    3. sekwencja taka sama (czyli wyslesz duuuzo danych, a klient odbierze stary pakiet)

    + masa innych bo oczywiscie sa miliony implementacji tcp, kazda majaca swoje wady. ale jak mowilem, nie sprawdzone.

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

    Domyślnie

    Cytat Napisał rax666 Zobacz post
    1. overflow numeru sekwencji
    nie bardzo wiem jak moze nastapic seq overflow... implementacja musialaby byc baaaardzo skopana bo jesli nastapi overflow to znaczy ze pole seq jest dluzsze, cala struktura pakietu IP sie zmienia i nie jest on juz poprawnym pakietem IP!
    Cytat Napisał rax666 Zobacz post
    2. kolizja checksumy
    mozliwe, tylko ze to nie jest blad... jaka jest szansa ze host A wysylajacy dane do B wysle w bardzo krotkim czasie dwa identyczne pakiety (poza retransmisja powiedzmy; patrz punk 3 ponizej) majace ten sam seq i inne dane ale dajace ten sam crc jak wczesniejszy pakiey gdy podawany przez A jest ciagly i kolejne pakiety sa kontyrnuacja transmisji? skoro juz o tym piszesz to podaj konkretne dane procentowe bo jestem bardzo ciekaw
    Cytat Napisał rax666 Zobacz post
    3. sekwencja taka sama (czyli wyslesz duuuzo danych, a klient odbierze stary pakiet)
    po przekroczeniu pewnej ilosci pakietow ktore nie dostaly ACK nadawca przestaje wysylac dane... klient nie potwierdza odebrania kolejnych jesli nie skompletuje wczesniej calej sekwencji... w przeciwnym wypadku robiac transmisje z A do B pomine celowo pakiet nr 13 bo akurat ten numer lubie (albo 7 bo ponoc szczesliwy) i wysle nastepne 20k pakietow... w pewnym momencie odbiorca przestanie potwierdzac ze odebral kolejne pakiety i bedzie czekal na retransmisje 13 i kolejnych pakietow ktorych odbioru nie potwierdzil - musi przeciez odbudowac stream
    Cytat Napisał rax666 Zobacz post
    + masa innych bo oczywiscie sa miliony implementacji tcp, kazda majaca swoje wady. ale jak mowilem, nie sprawdzone.
    jesli nie piszesz wlasnego OS'a tylko uzywasz czegos co juz istnieje, to nie jest Twoj problem... dla autorow aplikacji za cala ta zabawe odpowiada stos TCP/IP dostarczany przez OS i jesli sa w nim bledy to nie robota autora aplikacji aby to naprawiac tylko autora/wydawcy OS'u - koneic kropka.

    @autor - jesli Twoim problemem jest poprawna implementacja transferu w aplikacji to mozesz to sobie odpuscic - OS robi to za Ciebie swoim stosem TCP/IP... chyba ze piszesz kawalek kernela albo reimplementujesz stos TCP/IP - wtedy odesle Cie do RFC - caaaaalej serii abys poczytal jak to trzeba zrobic aby dzialalo z juz istniejacymi systemami.
    Ostatnio edytowane przez TQM : 09-16-2009 - 22:31
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  7. #7

    Domyślnie

    Cytat Napisał TQM Zobacz post
    @autor - jesli Twoim problemem jest poprawna implementacja transferu w aplikacji to mozesz to sobie odpuscic - OS robi to za Ciebie swoim stosem TCP/IP... chyba ze piszesz kawalek kernela albo reimplementujesz stos TCP/IP - wtedy odesle Cie do RFC - caaaaalej serii abys poczytal jak to trzeba zrobic aby dzialalo z juz istniejacymi systemami.
    Interesuje mnie tylko impletacja transferu... Zależy mi na nie sprawdzaniu ( w sensie że przeze mnie ) czy pakiet dotarł czy nie i czy w dobrej kolejności, czyli jak wyśle np 200znaków to te 200znaków w 100% dotrze bez mojej "interwencji"... I jeszcze pytanie mam odnośnie wysyłanie danych binarnych, wysyłał będę tylko tekst czyli znaki ASCII, podobno lepiej jest wysyłać wszystko zapisane binarnie, czy to prawda ?

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

    Domyślnie

    prawda w sensie ze jak masz dane binarne wyslac jako tekst to musisz przerobic na ASCII bo "tekst" to dla mnie dokladnie 7-bit ASCII - strata czasu IMHO. Jesli masz wlasny protokol transmisji to nie baw sie w ASCII tylko lec binarnie, jesli np robisz cos po HTTP(S) to musisz sprowadzic najczesciej lub przynajmniej czesciowo do formy tekstowej - zobacz wymagania protokolu na ktorego grzbiecie chcesz smigac.
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  9. #9

    Domyślnie

    Cytat Napisał TQM Zobacz post
    prawda w sensie ze jak masz dane binarne wyslac jako tekst to musisz przerobic na ASCII bo "tekst" to dla mnie dokladnie 7-bit ASCII - strata czasu IMHO. Jesli masz wlasny protokol transmisji to nie baw sie w ASCII tylko lec binarnie, jesli np robisz cos po HTTP(S) to musisz sprowadzic najczesciej lub przynajmniej czesciowo do formy tekstowej - zobacz wymagania protokolu na ktorego grzbiecie chcesz smigac.
    Mam jakieś np. 2tyś znaków i wysyłam je normalnie przez send... Ma to dolecieć do klienta na drugim kompie i tyle, zależy mi na tym żeby to było jak najszybciej ale nie chce korzystać z UDP.

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

    Domyślnie

    No to mozesz robic binarnie - nie widze problemu
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

Strona 1 z 2 12 OstatniOstatni

Podobne wątki

  1. qemu i połączenie FTP
    By Y4st3r in forum Linux
    Odpowiedzi: 5
    Autor: 06-20-2009, 10:54
  2. Serwer GG - Połączenie = ERROR
    By ShutDown in forum Domeny/Serwery
    Odpowiedzi: 1
    Autor: 03-24-2008, 20:01
  3. Virtualbox - połączenie z netem
    By Bouzer in forum Linux
    Odpowiedzi: 0
    Autor: 02-13-2008, 00:04
  4. Połączenie z serrwerem
    By andrew8666 in forum Newbie - dla początkujących!
    Odpowiedzi: 3
    Autor: 07-07-2007, 16:41
  5. Połączenie internetowe
    By Micr0 in forum Linux
    Odpowiedzi: 16
    Autor: 07-06-2007, 17:13

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