C# połączenie UDP unicast poza LAN nie działa prawidłowo

0

Witam ... mam problem z połączeniem po UDP:<font size="3"></span>

[SERWER]

UdpClient serverUDP;
IPEndPoint remoteIP = new IPEndPoint(IPAddress.Any, 0);

(konstruktor)
serverUDP = new UdpClient(socket);

najpierw serwer oczekuje na połączenie po kliknięciu buttona:
byte[] bstart = serverUDP.Receive(ref remoteIP);
serverUDP.Connect(remoteIP);</li> </ul> </li> </ul>

*** - następnie w pętli wysyła datagramy ~63750b i odbiera wiadomość od klienta
for(::)
{ //tutaj przygotowywane są dane do wysłani

  //UP
   serverUDP.Send(HTabByeRealSend, HTabByeRealSend.Length);

  //DW
  bwiad = serverUDP.Receive(ref remoteIP);

}

[KLIENT]

UdpClient clientUDP;
IPEndPoint remoteIP;

po kliknięciu buttona łączy się z serwerem
clientUDP = new UdpClient();
remoteIP = new IPEndPoint(IPAddress.Parse(localIP), socket);
clientUDP.Connect(remoteIP);
clientUDP.Send(new byte[1], 1);
(timer1.Enabled = true;)</li> </ul> </li> </ul> * - teraz Timer robiący za pętle pobiera dane i wysyła ~ 10b, żeby serwer wiedział, że klient już skończył mielić otrzymana paczkę + info o stanie klienta public void timer1_Tick(object sender, EventArgs e) { //DW data = clientUDP.Receive(ref remoteIP);
     //UP
     clientUDP.Send(bwiad, bwiad.Length);

}

Wszystko działa pięknie i wspaniale i wspaniale ale tylko jeśli działa na 2 kompach w lanie i łączę się
np: podaję u klienta B ip servera A czyli 192.168.1.91

-KOMP A (server192.168.1.91) <---> ROUTER <----> KOMP B (klient192.168.1.65)
-oczywiście routerze jest przekierowanie socketa 48080 (którym sa dane wymieniane) na ip KOMP-a A

problem pojawia się przy moim stałym ip 87.205.X.X, gdyż, gdy podam go klientowi programy zawieszają się a licznik wysłanych i odebranych pakietów od klienta wynosi kolejno:
dla pobranych 4 i wysłanych 4; w sumie pobiera 255000b i wysyła 40b po czym się wywala i nic się ani nie pobiera, ani nie wysyła

np: podaję u klienta B ip servera A czyli 87.205.X.X

-KOMP A (server192.168.1.91) <---> ROUTER <----> (<-87.205.X.X) KOMP B (klient192.168.1.65)

Czy może mi ktoś pomóc rozwiązać ten problem ? ... jestem już stracznie zdesperowany bo od tygodnia nie mogę nic wymyślić. :(

0

-KOMP A (server192.168.1.91) <---> ROUTER <----> KOMP B (klient192.168.1.65)
-oczywiście routerze jest przekierowanie socketa 48080 (którym sa dane wymieniane) na ip KOMP-a A
Przekierowanie portu na routerze podczas przesyłania wewnątrz tej samej podsieci nie ma nic do rzeczy i nie jest potrzebne.

problem pojawia się przy moim stałym ip 87.205.X.X, gdyż, gdy podam go klientowi
Temu samemu klientowi? Operowanie na zewnętrznych IP od wewnątrz podsieci lubi się kaszanić lub w ogóle nie działać.

Można dokonywać gimnastyki z ustawieniami na routerze, ale jeśli chcesz prawidłowo przetestować transmisję poprzez zewnętrzne IP, powinieneś dysponować drugim, niezależnym łączem.

0

@Azarien sprawdziłem poza lanem... wszystko działa ale tylko jeśli wysyłam MAX 1250B w ciągu 1 sek w innym wypadku mój router odcinany jest od internetu... zupełnie jakby się robił atak DoS. Nie rozumiem z jakiej paki się tak dzieje, i dlaczego nie mogę wysyłać więcej... może trzeba ustawić jakiś max bufor etc. ??? ... wydaje mi się, że 100 000 b na sek to bardzo mało przy 2 Mb/s przepustowości.

0

10 bajtow i naglowki sizeof(ethernet2+ip+udp), sporo tego bedzie.

0

Problemem nie jest chyba transfer, tylko wielkość pakietu.
Spróbuj wysyłać w małych paczkach - po kilobajcie.

0

Na to (i po czesci, ze transfer moze byc wiekszy ale nie przebije 2M) chcialem zwrocic uwage. Raz, ze to co robisz jest malo efektywne a dwa ze niektorzy moga taki transfer za podejrzany uznac.

0

Napisałem sobie kodek do tego i zmniejszyłem ilość danych.

Dane: 120 000b kodek średnio zmniejsza mi wysyłane dane o 40% + wymiana tylko różniących się danych... otrzymuję z tego oko 80% mniejszy rozmiar czyli z 120 000b oko
5 000b - 40 000 b ... w związku z tym na jedną sesję nigdy nie mam więcej do wysłania niż pełny datagram. Oczywiście w sek mam 8-10 takich sesji.

Problem jest w tym, że metody (UP i DW) x 2 są również bardzo - mega czasochłonne a ja potrzebuję te dane w czasie niemal rzeczywistym.

Mógłby mi ktoś podpowiedzieć, jak zwiększyć wydajność ? może są jakieś gotowe metody, które zmniejszają wielkość strumienia, albo przyspieszają upload po UDP [???]

----------- Zauważcie, że coś tu się NIE ZGADZA... gdyż oglądając film na YouTube pobieramy na min średnio 6 000 000b, czyli 100 000b/s, a przy 30FPS bo taki jest standard 3 333b na sesję klatki u mnie to jest 5 000b... a przecież nie jest jakimś problemem oglądać nawet 10 klipów na raz !!! więc jakim cudem mamy takie ograniczenia ?, że możemy przez WAN wysyłać max 1 000b/s !!! ???...

PS. Do tego o ile pamiętam to YT działa w TCP więc o WTF ?

PS2: A może używanie portu 48080 coś się kopci ? może powinienem stosować port 69 od TFTP albo 123 socket od NTP ???

0

PS 3: Znalazłem... problem był w ustawieniu możliwości fragmentacji wysyłanych danych

serverUDP.DontFragment = true;

taka mała zmiana przy inicjalizacji pozwala na wysyłkę już 1380b na sesję !!! ale niestety sam nadal nie potrafię przebić wyniku, który posiada YT... 3 333b

Z resztą jakim cudem skonwertować obraz do takich rozmiarów ??? (nie mówię tu o ustawieniu 1bpp)

0

A spróbowałeś z wysyłaniem większej ilości ale małych pakietów, czy dalej wysyłasz takie dżambo?

0

@Azarien próbowałem i im mniej wysyłam tym działa wolniej... bo czeka na 10b - odpowiedź klienta, który mieli to co dostaje z 10ms...

A jeśli bym wysyłał np: zamiast na 1 port 48080 na 3 porty pod rząd np: 48080, 48081, 48082,48083 w innych wątkach

To czy działało by szybciej ? ...

Już próbowałem wysyłać na ten sam port po kilka sesji ale nadal to samo.

PS.: Nie da się stworzyć tablicy klientów, która będzie odbierać dane... trzeba wszystko ręcznie pisać bo inaczej pokazuje się błąd, iz trzeba uzyć Bind a nastepnie, gdy sie uzyje Client.Bind(remote) odbierana jest tylko1 pakiet.

0

Ale YT używa protokołu TCP i :

Tam sobie ustala MTU i wysyła w pakietach (patrząc u mnie po 1460 bajtów danych na pakiet).
Protokół TCP ma wbudowane mechanizmy potwierdzenia z automatu (i w dodatku istnieją rozszerzenia wersji podstawowej pozwalające na optymalizacje - potwierdzana jest większa liczba pakietów).

Jeśli wybierasz małe pakiety to zapychasz łącze samymi nagłówkami np:

Ethernet2 14 bajtów
IP 20 bajtów
UDP 8 bajtów

42 bajty

i twoje dane 10 bajtów to około 20% transferu a i do tego potwierdzenia ... toż to gorsze od ATM któremu zarzucano nadmierny nagłówek (hasło do szukania > message packetization, optimal packetization.

Jak sprawdzasz swój kod ? Upload jest mniejszy zazwyczaj w sieciach więc od Ciebie nie da się wykręcić zapewne takiego transferu jak do Ciebie. Jaki wynik chcesz przebić ? Kompresji czy przesyłania bo się już pogubiłem.

0
matzo napisał(a)

@Azarien próbowałem i im mniej wysyłam tym działa wolniej... bo czeka na 10b - odpowiedź klienta, który mieli to co dostaje z 10ms...

A po co? W ten sposób wynajdujesz TCP, tylko gorsze. UDP jest do tego, by NIE czekać za każdym pakietem na potwierdzenie.
Wywal te potwierdzenia i zobaczysz jak ci transfer wzrośnie.

0

Potrzebuję tych danych (10b) i nie są one tylko dla widzimisię, bo determinują dalszą pracę servera. Dopisałem sobie jeszcze jeden watek na inny port i dopiero wtedy zaczęło troszkę szybciej działać (po lanie). Nie zmienia to wszystko faktu, że na dal nie mogę osiągnąć nawet 600kb/s (po WAN)... nawet jak wywaliłem na chwilę odpowiedź klienta.

0

No ale skoro twoje dane to 20% to osiągasz prędkość 3000kb

0

Przerobiłem to w taki sposób, że klient interpretuje dane już nie po tej paczce kontrolnej lecz po wielkości otrzymanych D.G... niestety znowu się coś "zdupiło" tym razem podejrzewam, że jest to wynik jakiegoś przepełnienia max buforu odbieranych danych... bo mimo, że działa jako tako to program zatrzymuje się po pewnym czasie i nie chce odbierać pakietów.

Wiem, że dla TcpClient jest taka opcja jak ReciveBuffer ale niestety nie mam pojęcia jak to ustawić przy UDP ? Czy ktoś z was wie.. co zrobić w takiej sytuacji ? może powinienem co kilka sek. zmieniać port i tworzyć nowe połączenie... ale czy to znowu nie spowoduje spowolnienia głównej wysyłki ?

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