Wysyłanie danych serwer - klienci

Odpowiedz Nowy wątek
2011-10-17 22:46
0

Z tematu sieci w jestem troszkę zielony więc proszę o pomoc.
Jak najlepiej rozwiązać problem napisania czegoś na wzór chata?
Za cel nie stawiam sobie stworzenia narzędzia do "komunikacji tekstowej", a gry sieciowej (chat podaję więc jako przykład który ma za zadanie naświetlić mój problem).

W transmisji tej bardzo zależy mi na szybkości oraz dokładności w wysyłaniu bitów / danych (więc pewnie protokół UDP odpada?). Proszę o pomoc.

Pozostało 580 znaków

2011-10-17 22:57
0

Pytanie, które powinieneś sobie postawić to: Jak dużo danych i jak często będziesz wysyłał?

Zadaniem serwera jest odpowiadanie na prośby. Przykład wymiany zdań:
K: Chcę się zalogować z loginem XXX i hasłem YYY
S: Hasło prawidłowe

K: Wyślij mi mapę
S: ... <w dowolny sposób zapisana mapa>

K: Chciałbym poruszyć się tutaj <x,y>
S: OK

K: Co się wydarzyło
S: ... <lista zdarzeń z czasami>

...

Chodzi generalnie o to, żeby to był dialog - taki kod najłatwiej się analizuje ORAZ klient prosi tylko o te dane które potrzebuje, a resztę jest w stanie sam obliczyć.


░█░█░█░█░█░█░█░█░█░█░█░

Pozostało 580 znaków

2011-10-18 18:17
0

Jeśli chodzi o częstotliwość wysyłanych danych to będzie ona bardzo wysoka, ale będzie to niewielka porcja bitów.

Pomysł jest mniej więcej taki:
Jest aplikacja która na formie ma jakieś tam przyciski. Po włączeniu dajmy na to button1 (u siebie) ta informacja musi zostać przesłana jakoś do innych ludzi (ze mną połączonych) i u nich ma też wykonać się akcja z przycisku button1. Tak samo jeśli jakiś ktoś przyciśnie np. button3 to to też musi pójść w świat dla innych i u każdego połączonego ten przycisk musi się uruchomić.

Zależy mi tu bardzo na prędkości oraz dokładności w wysyłaniu tych danych. Na pewno takie coś jest możliwe bo w końcu w takim np. Couter Strike więcej rzeczy jest wysyłanych i odbieranych a wszystko to działa bardzo szybko.

Mam nadzieję ze jasno to wytłumaczyłem.

Pozostało 580 znaków

2011-10-18 20:20
1

po pierwsze wysłanie 1000 razy po 1 bajcie będzie dużo wolniejsze niż wysłanie 1 raz 1000 bajtów. Zobacz sobie jak wygląda ramka TCP. Sam nagłówek ma min. 16 bajtów więc jak wysyłasz 1000 razy po 1 bajcie tak naprawdę wysyłasz 1000 (16 + 1) czyli 17.000 bajtów. Jeśli wysyłasz 1 raz 1000 bajtów tak naprawdę wysyłasz 1 (1000 + (16 * (1000/536 => 2)) czyli 1.032 bajtów. 536 to domyślny maksymalny rozmiar danych w jednej ramce. Jeśli mamy 1000 bajtów a max w jednej ramce może być 536 to zostaną wysłane co najmniej dwie ramki. To tak trochę teorii abyś zrozumiał, że wysyłanie małych paczek nie zawsze jest dobre.

A teraz co do konkretów to bez kodu i Twojego "testu szybkości" (dlaczego uważasz, że jest za wolno) wątpię aby ktokolwiek powiedział coś sensownego


- Ciemna druga strona jest.
- Nie marudź Yoda, tylko jedz tego tosta.
Google NIE GRYZIE!
Pomogłem - kliknij
edytowany 1x, ostatnio: Misiekd, 2011-10-19 00:04
dziękuje za odpowiedź. - Piotruch88 2011-10-18 22:21
btw 1000 x pakiet 1B to też 1000 x opóźnienie, a 1 pakiet x 1000B, czyli jak Misiek napisał dwie ramki, to tylko 1 x opóźnienie, bo obie ramki są nadane od razu, bez czekania na potwierdzenie otrzymania poprzedniej ramki. - ŁF 2011-12-06 12:44

Pozostało 580 znaków

2011-10-26 18:45
0

OK w takim razie chciałbym spróbować stworzyć kod, ale tym razem na Synapse zamiast INDY (po co skoro na tym badziewiu i tak to nie działa tak jak ja chce). Komponenty (Synapse) bardzo szybkie poza tym, że dla kogoś kto do tej pory używał tylko INDY bardzo nie intuicyjne w użyciu.

Jak np. odbierać dane skoro tam nie ma czegoś takiego jak zdarzenia OnRecBuff (czy coś w tym stylu). Znalazłem na googlach takiego gotowaca:
http://stackoverflow.com/ques[...]nnot-receive-data-from-socket
ale to nie działa mi w ogóle.

Mógł by ktoś zapodać jakimś przykładem na łączenie się serwera z klientem / klientami w synapse?

Pozostało 580 znaków

2011-10-27 02:56
0

przypomnij się koło południa to wrzucę przykładowy kod bo już mi się nie chce dzisiaj :p

tutaj http://www.speedyshare.com/files/30946909/Simple_MultiChat.rar masz przykład jak można się komunikować po tcp z użyciem synapse


- Ciemna druga strona jest.
- Nie marudź Yoda, tylko jedz tego tosta.
Google NIE GRYZIE!
Pomogłem - kliknij
edytowany 1x, ostatnio: Misiekd, 2011-10-27 15:00
Bardzo, bardzo dziękuje. Zaraz przejrze ten przykład. - Piotruch88 2011-10-27 18:12

Pozostało 580 znaków

2011-12-06 12:14
0

Teraz gdy miałem chwilę czasu zabrałem się za ten program.
Wydaję mi się (aczkolwiek jeśli się mylę to proszę mnie poprawić), że przesyłanie danych przez sockety jest zbyt wolne dla mojego programu. W mojej domowej sieci wysłanie danych z jednego komputera na drugi powoduję znaczące opóźnienia w mojej grze.

A teraz co do konkretów to bez kodu i Twojego "testu szybkości" (dlaczego uważasz, że jest za wolno) wątpię aby ktokolwiek powiedział coś sensownego

Wysyłam więc w tym linku:
http://www.speedyshare.com/file/Hn39d/Simple-MultiChat.7z
zarys tego jak aplikacja ta miała by wyglądać
(biblioteki midi mogę podesłać, jak ktoś jest tym zainteresowany)

Po przetestowaniu widać wyraźnie, że szybsze wciśnięcie klawiszy jest zbyt wolno odwzorowywane na sąsiednim komputerze. Mimo to dziękuje jeszcze raz zainteresowanie tematem i proszę o jakieś wskazówki np. co robię źle.

Pozostało 580 znaków

2011-12-06 12:30
0

jak dla mnie działa bez zauważalnego gołym okiem opóźnienia. Sieć lokalna, jeden komp karta 1Gb na płycie -> swich 100Mb -> AP 54Mb -> laptop wifi wbudowana. Jedyny szkopuł w tym, że wywala klienta po np. włączeniu perkusji czy zmianie instrumentu


- Ciemna druga strona jest.
- Nie marudź Yoda, tylko jedz tego tosta.
Google NIE GRYZIE!
Pomogłem - kliknij

Pozostało 580 znaków

2011-12-06 12:59
0

Tak to będę musiał jeszcze te błędy ze zmianami instrumentów poprawić, to wiem.
Trochę mnie to zdziwiło co napisałeś, bo u mnie dwa lapki połączone po kablu (z kartami chyba gigowymi) i były opóźnienia przy szybszych dźwiękach. O moim nędznym wifi już moim nie wspominam, bo musiałem je ze standardu wifi 802.11 n do 802.11 b zredukować (choć szybkość transmisji była podobna jak na kablu.)

Czy np u Ciebie Misiekd da się bez opóźnienia wygrać tak około 4 dźwięków na sekundę?

Korzystając z niezabezpieczonej sieci wifi mojego sąsiada chciałem zrobić połączenie przez internet, ale nie wiem czemu program nie widzi serwera. Port Tcp przekierowany na routerze, firewall wyłączony. Będę musiał jeszcze z tym powalczyć bo jestem dość zdeterminowany.

Pozostało 580 znaków

2011-12-06 16:30
0
Piotruch88 napisał(a)

Czy np u Ciebie Misiekd da się bez opóźnienia wygrać tak około 4 dźwięków na sekundę?
napiszę tak - jak przycisnę na jednym to na drugim gra praktycznie od razu, nie widać jakiegoś opóźnienia czy czegoś podobnego. Inna sprawa, że jak naciskam szybko to klient, który ma powtarzać po prostu się gubi. odpal sobie na tej samej maszynie co klient, który odbiera i gra np. telneta telnet adres_serwera 12345 i zobacz, że wiadomości do niego przychodzą wszystkie a grane nie wszystkie

albo wyświetlaj sobie przyjście każdej wiadomości w okienku chatu razem z godziną (z milisekundami) to zobaczysz co przychodzi a co jest grane


- Ciemna druga strona jest.
- Nie marudź Yoda, tylko jedz tego tosta.
Google NIE GRYZIE!
Pomogłem - kliknij
edytowany 1x, ostatnio: Misiekd, 2011-12-06 16:31

Pozostało 580 znaków

2011-12-06 20:43
Oho
0

Trochę mnie to zdziwiło co napisałeś, bo u mnie dwa lapki połączone po kablu (z kartami chyba gigowymi) i były opóźnienia przy szybszych dźwiękach.

'Coś opóźnia' np. router, albo jakiś antywirus czy coś innego. Przez internet nie da się szybciej niż przez internet. Tego nie unikniesz.

Korzystając z niezabezpieczonej sieci wifi mojego sąsiada chciałem zrobić połączenie przez internet, ale nie wiem czemu program nie widzi serwera. Port Tcp przekierowany na routerze, firewall wyłączony. Będę musiał jeszcze z tym powalczyć bo jestem dość zdeterminowany.

Tak, atakuj sieć sąsiada. to jest najlepszy sposób na testowanie opóźnienia. Ja bym raczej strzelił jakieś darmowe proxy bo chociaż byś nie miał kłopotów z legalnością.

Ażeby przyśpieszyć prędkość połaczenia robi to się tak w FPSach itd.:
1.Zbieramy dane i liczymy sobie ms
2.Co ileś ms wysyłamy zgromadzone dane
3.Co te ileś ms odbieramy także dostarczone dane i się do nich stosujemy.
4.Jeżeli nie otrzymujemy danych to próbujemy symulować zachowanie obiektów ruchomych (np. ciągle je przemieszczamy tak jak się wcześniej przemieszczały).

Pozatym, mi się wydaje, że kolego masz niesamowite wyobrażenie o prędkości połączenia. Generalnie w połaczeniu ważniejsze niż czas z A do B jest istotniejsza jest niezmienność tego czasu oraz w miarę spora przepustowość (czyli nie zapchamy się).

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