Witam, chcę sobie napisać prosty soft, który ma obsługiwać dane przychodzące w pakietach TCP.

Pierwszy program (serwer TCP) ma komponent ProgressBar1, na którym chcę wyświetlać dane, które przychodzą w postaci tekstu .
Drugi program ma być jego klientem. W nim mam suwak, który w zdarzeniu OnSuwakChange ma wysyłać przez TCP pakiety z aktualną wartością suwaka.

Generalnie transmisja działa, pasek się porusza, ale problem pojawia się gdy zacznę szybciej poruszać suwakiem, wtedy program dostaje jakby sklejony pakiet, np. i wyrzuca wyjatkiem jakbym chciał zamieniać "VALUE=xxx" na tym integer.
Aktualna wersja w ogóle pokazuje, że przekroczyłem zakres operatora "[]" i już nei wiem co z tym zrobić..



Jak najlepiej coś takiego obsłużyć? Dodam, że program nic konkretnego nie robi, tylko po prostu uczę się korzystać z protokołu TCP

Jakby ktoś miał zupełnie inną wizję takiego programu to śmiało pisać

_________________
Pozdrawiam:
Mikołaj

która to wersja ? Buildera ?

przede wszystkim poleciłbym ci na początek zabawę ale nie w TCP do takich celów a UDP. Pytam która wersja bo w wielu powinny być dostępne fajne komponenty INDY 9.x

komunikacja bezpołączeniowa jest łatwiejsza do realizacji bez udziału wątków, a TCP czyli połączeniowa .... no można pojechać trochę na zdarzeniach ale to docelowo nie będzie działać za dobrze ...

Co do kodu nie pomogę bo chociaż Borland mi bliski to jednak ja męczyłem Delphi a tu się jeszcze nie odnajduję

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Generalnie to ja sobie przepisuje z delphi do C++.

Borland 6 - indy już wcześniej zainstalowałem, teraz właśnie męczę komponent IdTCPServer.

UDP już się bawiłem
TCP musi być ze względu właśnie na typ połączeniowy, tylko tak moge uzyskać połaczenie w dwie strony przy poblokowanych portach za NATem

Potestowałem komponent ServerSocket i się okazuje, ze to on czasami bzdury odbiera, w sensie że nie odbiera jako cały pakiet tylko sobie czasami obcina w jednym pakiecie końcówkę, a dodaje ją do nastepnego, więc tu pies pogrzebany

-- 37 minutach --

Mirku, powiedz mi jak w komponencie INDY odczytywać na bieżąco dane? teraz mam tak, że dopiero jak się klient rozłączy to wskakuje mi cały bufor...

_________________
Pozdrawiam:
Mikołaj

W dwie strony nie uzyskasz - tzn z domciu nawiążesz połączenie gdzieś ze światem i będziesz miał po prostu ruch zwrotny zapewniony

ale po UDP można dokładnie tak samo

nie żebym cię na siłę przekonywał do UDP ale podpowiadam

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Jak to zrobić z UDP? tylko dlatego przesiadłem się na TCP żeby był ruch w 2 strony. Mam w domu stałe zewnętrzne IP i mogę z domem nawiązać połączenie.

Myślałem, że to jest taka specyfika TCP/UDP

Poza tym, czy aby nie jest możliwe, że jakiś pakiet może gdzieś zaginąć przy UDP? wiem, że o ile w LAN to raczej nie ma gdzie zginąć, to w internecie jednak. W dodatku ostatecznie chcę sterować z telefonu suwakami na komputerze, a zwrotny ruch potrzebny mi, żeby zaaktualizować kontrolki w telefonie.

_________________
Pozdrawiam:
Mikołaj

takie rzeczy to były w OWYM czasie, gdy wprowadzano pierwsze sieci komputerowe, oparte jeszcze na kablach BNC ... dawno i nieprawda

no ! ... może nie do końca nieprawda ponieważ oczywiście sam standard tej warstwy stosu nie zapewnia potwierdzeń to jednak w dzisiejszych sieciach w tym także w internecie - trzeba by się bardzo postarać żeby gubić pakiety



no to właśnie źle myślałeś bo na pakiet UDP można odpowiedzieć zwrotnie i dotrze ta odpowiedź dokładnie do nadawcy jak w TCP

Tylko że ....

trzeba wiedzieć o jednym - oczywiście że tzw Broadcasty - nie przedostaną się przez routery bo wszystkie wcześniej czy później po kilku tzw "chop'ach" zostaną wybite w pień

ale brodacastami to się można bawić w LAN'ie

jeśli zaś chcesz w całej sieci w tym w internecie to WYSTARCZY zaadresować datagram i JUŻ to wsio ...

a po drugiej stronie użyć opcji REPLY, co spowoduje że z datagramu zostanie wykorzystana cała informacja zwrotna o nadawcy, jego IP i port ale co ważne MACADDRESS ... i informacja zwrotna potulnie dofrunie do nadawcy

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No dobra, czyli jak mam odblokowany dajmy na to u uslugodawcy przychodzacy port tylko 21 i 80 to jestem w stanie po wyslaniu pakietu UDP z tego kompitera uzyskac odpowiedz z serwera UDP tak jak w przypadku TCP?

Chodzi o to, ze z komorki jak przez internet wyslalem pakiet do komputera i doszedl, to jestem w stanie tez w druga strone?

Jeszcze jedno. Ile on bedzie czekal na taka odpowiedz? Bo to wlasnie ta komorka docelowo ma odbierac dane

Wysłane z mojego GT-I9500 za pomocą Tapatalk 4

_________________
Pozdrawiam:
Mikołaj

A co to za różnica jaki port ? Już w Bluebooku

http://atnel.pl/mikrokontrolery-avr-jezyk-c.html

masz przykłady jak to uzyskać z pełnym powodzeniem od strony nawet mikrokontrolera więc chyba nie myślisz że ze strony PC'ta miałoby to stanowić jakiś problem



Tak, ale TYLKO jako odpowiedź na ten datagram który nadleciał (REPLY), a nie że ty sobie wymyślisz aby stworzyć nowy datagram, opatrzyć go TYLKO docelowym adresem IP - bo tak nie da rady (przynajmniej wprost) ... bo nie wprost to też dałoby radę ale zostawmy to.



Tyle samo co gdybyś to robił przez TCP

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Może się to przyda. Napisałem kiedyś serwer TCP który służy do wyrzucania na konsole to co dostanie po sieci, używam go do wyświetlania logów z wielu maszyn w jednym miejscu. Do wysyłania po sieci można użyć netcata albo rsysloga.
Program został stworzony na podstawie poradnika "Beej's Guide to Network Programming"
http://beej.us/guide/bgnet/

main.cpp


server.h


server.cpp

_________________
Und schreien

Spring
Erlöse mich
Spring
...

No właśnie, a czy przypadkiem w TCP nie jest tak, że Klient nawiązuje połączenie z serwerem, a po nawiązaniu komunikacja już jest w obie strony?

W ten sposób jaki przedstawiasz, musiałbym cały czas wysyłać zapytania o dane do serwera, a to mnie nie satysfakcjonuje, gdyż nie byłoby płynności wtedy. Pewnie własnie o tym wspomniałeś tu:



Z tymi portami to jest taki problem, że iPlus blokuje WSZYSTKIE porty przychodzące, nie działa nawet port 80. Dlatego jestem zmuszony nawiązywać połączenie z urządzenia mobilnego, a nie stacjonarnego.

-- 8 minutach --

Oczywiście cały czas mówię o transmisji przez internet, bo przez LAN to żaden problem używać UDP

_________________
Pozdrawiam:
Mikołaj

Oczywiście, że tak jest i jeśli KONIECZNIE zależy na takiej funkcjonalności to jasna sprawa że trza iść w TCP



to dobrze rozumiem, jak mówiłem chciałem tylko zwrócić uwagę, że w UDP także można mieć informację zwrotną, a jak dobrze pomyśleć nad protokołem własnej komunikacji to nie stanowi to większego problemu.

Jeśli jednak nie chce się iść tą drogą to jak mówiłem zostaje TCP

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Hmmm.. A ma ktoś może jakiegoś śledzia?

Mam tu na myśli coś co w sumie nadawałoby się do działu rybnego

Jakiś program nawet w delphi, który radzi sobie z pakietami TCP?


http://4programmers.net/Delphi/INDY - tutaj jest przykład, ale jakoś to dziwnie rozwiązali, bo pakiet jest odbierany dopiero po rozłączeniu klienta, czyli żeby wysyłać strumień, musiałbym co chwilę go łączyć/rozłączać :/

_________________
Pozdrawiam:
Mikołaj

Może tu warto zajrzeć?

http://delphi.about.com/od/internetintr ... 20403a.htm

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]