Strona 1 z 5 123 ... OstatniOstatni
Pokaż wyniki 1 do 10 z 44

Temat: tcp zduplikowanyt ACK

  1. #1

    Domyślnie tcp zduplikowany ACK

    Dlaczego przy probie zamkniecia polaczenia dostaje zduplikowany ACK?
    Dlaczego wogule pakiez ma flage fin i ack ustawiona? DLa mnie jest to blad, bo po co ack idzie drugi raz?

    w programie to wyglada tak:
    connect()
    send()
    shutdown()



    listen()
    accept()
    while recv() != 0
    shutdown()



    Ostatnio edytowane przez linux_aa : 12-19-2010 - 03:32

  2. #2
    Zarejestrowany
    Sep 2009
    Skąd
    Z Nienacka
    Postów
    396

    Domyślnie

    Nie wiem, gdzie tu widzisz jakikolwiek błąd...

    ACK jest ustawiony wszędzie poza rozpoczynającą flagą SYN, także przy fladze FIN! A to, że w Twoim wypadku dwa razy potwierdza ten sam (ACK=4) spowodowane jest brakiem kolejnego datagramu do potwierdzenia. A o ile się nie mylę to protokół mówi jasno, aby potwierdzić ostatni odebrany. W tym wypadku 2 razy potwierdza to samo.

    Trochę zamotałem...

    Pozdrawiam

  3. #3

    Domyślnie

    @lojciecdyrektor
    zamotales tak, ze az nie wiem czy sie mylisz

    @linux_aa
    najpierw Ty mu wysylasz psh,ack x.128 do x.1
    pozniej x.1 potwierdza
    x.128 wysyla flage fin,ack do x.1 - bo konczymy polaczenie
    x.1 potwierdza, ze dostal flage x.128
    x.1 tez chce konca polaczenia wiec wysyla fin,ack do x.128
    x.128 potwierdza otrzymanie fin,ack
    KONIEC

    tak to rozumiem, normalne zakonczenie polaczenia z roznymi numerami sekwencyjnymi podczas FIN-WAIT oraz roznymi numerami ACK podczas CLOSING
    Ostatnio edytowane przez Whizz_BANG : 12-19-2010 - 11:03

  4. #4

    Domyślnie

    ale po co sa dodatkowe acki przy psh i fin?
    przeciez w tych 2 przypadkach, acjk zostal juz wczesniej wyslany! Dlaczego 2x idzie to samo?

    Czy bylo by mozliwe takie cos?
    A -> B (SYN)
    B -> A (SYN/ACK)
    A - > B (ACK)

    A - > B (NULL)
    B - > A (ACK)

    A -> B (FIN)
    B - > A (ACK)
    B -> A (FIN)
    A - > B (ACK)

    obecnosc dodatkowego ack wprawdzie nie wplywa na nic negatywnie, ale po co 2 razy robic to samo, po co ack jest doklejany w pakietach fin i psh mimo ze wczesniej zystal wyslany pakiet zawierajacy tylko ack...

  5. #5

    Domyślnie

    Cytat Napisał linux_aa
    ale po co sa dodatkowe acki przy psh i fin?
    przeciez w tych 2 przypadkach, acjk zostal juz wczesniej wyslany! Dlaczego 2x idzie to samo?
    bo tak to dziala... ack, czyli acknowledgement - potwierdzenie; tcp nie lubi burdelu w stylu - dalem cos i jestem zadolony, ze cos dalem i kij mnie obchodzi co sie dzieje z tym dalej; tcp dziala na zasadzie - jak juz cos robie to oczekuje potwierdzenia, ze jest ok

    Cytat Napisał linux_aa
    Czy bylo by mozliwe takie cos?
    A -> B (SYN)
    B -> A (SYN/ACK)
    A - > B (ACK)

    A - > B (NULL)
    B - > A (ACK)

    A -> B (FIN)
    B - > A (ACK)
    B -> A (FIN)
    A - > B (ACK)
    mniej wiecej tak to wlasnie jest, nie bede poprawial, podam pierwszy lepszy link z google:
    TCP Connection Close
    Ostatnio edytowane przez Whizz_BANG : 12-19-2010 - 18:50

  6. #6

    Domyślnie

    chyba nikt nie rozumie o co mi chodzi.
    doczytalem ze w polaczeniu tcp kazdy pakiet musi miec jakas flage, nie moze byc NULLi.
    i wlasnie dlatego jest fin/ack, rst/ack i psh/ack.

    ale dlaczego tcp wymaga flagi? Nie wiem.

  7. #7

    Domyślnie

    ...wymaga, bo taki jest naglowek tcp...

  8. #8

    Domyślnie

    co ma naglowek do tego.
    nie ma flagi = pole jest ignorowane

    tak jak URG. ma on sens tylko jesli flaga jest ustawiona. W pakiecie SYN rowniez ack number jest bez znaczenia.
    Wiec jakby dostac pakiet bez ack, to mozna by go poprostu przekazac dalej, i nie ackowac zadnych danych.
    Nie wiem dlaczego ktos to zakompikowal do tebo stopnia, ze ack jest wymuszony, dla mnie to nie ma sensu, i szukam odpowiedzi na ten temat.

    Moze to ma zwiazek z tym zeby jakos sledzic polaczenie tcp? No ale od tego jest sequence number, a ack jaki ustaiwe taki zostanie przyjety.

    Zalozmy sytuacje, ze klient sie laczy z serwerem, i wysyla mu duzo danych, serwer nic mu nie wysyla procz ackow.
    Za kazdym razem jak klient wysyla dane, to musi miec ACK ustawiony. Serwer odbierajac te dane widzi flage ack, i zaznacza czesc danych jako odebrane, za kazdym razem jak dostwnie pakiet. Jest to BEZ SENSU, jes to DEBILIZM i strata energii na niepotrzebne instrukcje.

    Dlaczego ack jest wymagany? Dlaczego pakiet bez flag jest nielegalny?

  9. #9

    Domyślnie

    ... zaczyna mi to przypominac walke z wiatrakami

    Cytat Napisał linux_aa
    Dlaczego ack jest wymagany? Dlaczego pakiet bez flag jest nielegalny?
    bo tak dziala tcp?

    widze 2 opcje teraz:

    1) doczytaj jak dziala tcp, bo dalej bedziesz upieral sie przy wyimaginowanych problemach

    2)
    Cytat Napisał linux_aa
    Jest to BEZ SENSU, jes to DEBILIZM i strata energii na niepotrzebne instrukcje.
    napisz do tworcow protokolu tcp Cerfa i Kahna, ze sa idiotami i debilami (co z tego, ze caly swiat korzysta z tcp od kilkudziesieciu lat) - Ty bys to zrobil lepiej...

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

    Domyślnie

    TCP zapewnia ciaglosc transmisji, dlatego obie strony musza potwierdzac odbior danych od partnera.
    Potwierdzanie czesci pakietow danych wlasnie jest robione w TCP tak jak podajesz ale bufory nie sa tak duze jak Tobie sie wydaje, poza tym to co piszesz nie ma sensu - klient wysyla dane do serwera i pompuje i pompuje do smierci... a serwer nie odbiera danych od dawien dawna bo ma pelen bufor i brakuje mu jednego pakietu po drodze aby poskladac strumien danych do kupy... a klient nie ma sposobu aby sie o tym brakujacym pakiecie dowiedziec bo serwer nie wyslal ACK....

    takie cos nie ma sensu bo albo serwer albo klient nie wie jaki jest stan transmisji i czy wszystkie dane zostaly nadane i odebrane prawidlowo...

    poza tym gdyby to dzialalo tak ze klient moze mase danych wepchnac do serwera to juz widze jak mialbys serwery z GB RAM aby trzymac pakiety ktorych nie da sie poskladac

    1. Doczytac jak dziala TCP i dlaczego kazdy pakiet w TCP musi byc potwierdzony (ACK)
    2. Doczytac o Path MTU Discovery
    3. Doczytac o fragmentacji i ponownym skladaniu pakietow
    4. ... a jakby Ci sie nudzilo to mozesz jeszcze zerknac na TCP Sliding Window
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

Strona 1 z 5 123 ... OstatniOstatni

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