<sys/socket.h> pytanie o odbierane ramki

Odpowiedz Nowy wątek
2011-08-04 23:16
szymko
0

Witam przesyłam od dłuższego czasu ramki za pomocą gniazd przez tcp w trybie nieblokującym.
Wysyłam strukturę o wielkości 1500 bajtów a mój server odbiera to zawsze na dwa sposoby i tylko na dwa!
Albo pakiet 1452 B i wtedy 48
Albo całe 1500

Strasznie mnie to dziwi bo przecież maksymalne pole danych ramki to 1500 wiec niby powinno to być odbierane zawsze jako 1500.
Jednak używam trybu nieblokującego więc niby dane wcale nie musiały by przychodzić w całości i wtedy wersja pierwsza jest dla mnie zrozumiała, ale znowuż też nie do końca bo skoro zawsze by zwracał tyle ile ma aktualnie to dlaczego mój server zawsze powtarza ten sam wynik 1452 i 48?
Mógł by mi ktoś to wyjaśnić?

Pozostało 580 znaków

2011-08-04 23:22
Rev
0

To jedne z najpopularniejszych wartości MTU.


Pozostało 580 znaków

2011-08-04 23:44
szymko
0

W takim razie jeszcze jedno pytanie. Czy jeśli ustawię MTU na 1500 to nawet w trybie nieblokującym wysyłając ramkę 1500B będę również odbierał za pomocą recv albo 1500 albo -1?

Pozostało 580 znaków

2011-08-04 23:50
0
szymko napisał(a)

Strasznie mnie to dziwi bo przecież maksymalne pole danych ramki to 1500

A skąd to? Ja wiem że ilość danych wysyłanych czy odbieranych nie powinna być większa niż 1024B. W moich programach dla pewności nie wysyłałem więcej niż 512B.

Pozostało 580 znaków

2011-08-04 23:53
szymko
0

maksymalna wielkość pola danych ramki ethernet'owej

Pozostało 580 znaków

2011-08-05 09:23
Kumashiro
0

MTU określa maksymalną wielkość, nie minimalną. Pakiet może zostać podzielony przez urządzenia biorące udział w transmisji. Nigdy nie powinieneś polegać na tym, że dostaniesz dokładnie taką ilość danych, ile określa MTU. Możesz polegać na tym, że nie będzie więcej.

Pozostało 580 znaków

2011-08-05 10:55
0

Ok ok, ja pisałem jak to wyglądało w mojej praktyce. BJ też napisał że wysyłając 1kB możemy być względnie pewni że tyle dostaniemy po drugiej stronie, wysyłając więcej to już tak niekoniecznie. Ja dzieląc sobie pakiety na 512 bajtów nigdy nie miałem problemów z komunikacją, implementowałem FTP i HTTP.

Pozostało 580 znaków

2011-08-05 10:59
Kumashiro
0

Ale o jakich problemach z komunikacją mówisz? Wątek dotyczy protokołu niższej warstwy niż TCP i UDP.

Pozostało 580 znaków

2011-08-05 11:05
0
Kumashiro napisał(a)

Ale o jakich problemach z komunikacją mówisz? Wątek dotyczy protokołu niższej warstwy niż TCP i UDP.

EKhem..

szymko napisał(a)

Witam przesyłam od dłuższego czasu ramki za pomocą gniazd przez tcp w trybie nieblokującym.

Skoro ktoś coś wysyła gdzieś to znaczy że jakaś komunikacja następuje prawda? W ogólności chodzi mi o to że używająć send(), sendto(), recv(), recvfrom() nie powinno się formować pakietów danych dłuższych niż 1024B.

edytowany 1x, ostatnio: several, 2011-08-05 11:05

Pozostało 580 znaków

2011-08-05 11:24
Kumashiro
0
several napisał(a)

Skoro ktoś coś wysyła gdzieś to znaczy że jakaś komunikacja następuje prawda?

Ale wiesz co to jest stos TCP/IP?

several napisał(a)

W ogólności chodzi mi o to że używająć send(), sendto(), recv(), recvfrom() nie powinno się formować pakietów danych dłuższych niż 1024B.

Nie wiem skąd masz takie rewelacje. Fragmentacja nie następuje w warstwie TCP czy UDP. Jedyne, o co możesz się tam martwić, to wielkość bufora systemowego ale jest ona większa niż 1kB. Ograniczanie wielkości pakietu danych w warstwie TCP nie ma sensu, gdyż nie wiesz czy po drodze jakiś ruter nie poszatkuje Ci tego pakietu na fafdziesiąt mniejszych, a nie będziesz przecież implementował w swoim programie MTU Discovery.

Pozostało 580 znaków

2011-08-05 11:41
0
Kumashiro napisał(a)

Ale wiesz co to jest stos TCP/IP?

Nie, widocznie źle zrozumiałem problem.

Kumashiro napisał(a)
several napisał(a)

W ogólności chodzi mi o to że używająć send(), sendto(), recv(), recvfrom() nie powinno się formować pakietów danych dłuższych niż 1024B.

Nie wiem skąd masz takie rewelacje.

Już pisałem, z własnej praktyki. Wysyłając więcej raz na jakiś czas pakiet bywał szatkowany jak to określiłeś. Wysyłając dużo więcej pakiety nie dochodziły w całości, w sensie nie dochodziły wszystkie. Formując mniejsze pakiety nigdy nie miałem problemów z otrzymaniem odpowiedniej ilości informacji.

edytowany 1x, ostatnio: several, 2011-08-05 11:41

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0