komunikator c#

[azyl]

Witam

 

Pisze komunikator internetowy w C#

 

Zrobilem wstepny projekt laczenia sie za pomoca TCP, jednak nie dziala tak jak powinien. Kiedy wysle wiadomosc z klienta do serwera, nie moge nic zrobic jesli nie zamkne polaczenia. Nie ma wiec mowy o wyslaniu nastepnej wiadomosc czy odebrania wiadomosc od serwera bo program sie wiesza.

 

Czy ja popelniam blad czy tak dziala protokol TCP ?

Wiem, ze mozna zrobic komunikator na socketach, jednak chce sie najpierw upewnic czy tcp definitywnie odpada, bo mam w nim juz troche kodu napisanego.

[mystery]

TCP jest protokołem połączeniowym, moim zdaniem powinieneś spróbować raczej z UDP, gdyż wiadomości tekstowe mają raczej niski priorytet, zazwyczaj są bardzo krótkie i wysyłane są relatywnie rzadko. Nie potrzeba rezerwować zasobów na nie i utrzymywać połączenia. Sockety wydają się być chyba najlepszym rozwiązaniem.

 

pozdrawiam

m

[azyl]

wysyłane są relatywnie rzadko. Nie potrzeba rezerwować zasobów na nie i utrzymywać połączenia. Sockety wydają się być chyba najlepszym rozwiązaniem.

 

 

Nie wiem czy to jest do konca tak z polaczeniem. Jezeli rozmawiam z kims przez komunikator to zwykle polaczenie miedzy serwerem a klientem komunikatora jest przez caly czas rozmowy. Sugerujesz, ze kazda wyslana wiadomosc powinna na nowo otwierac polaczenie i po przeslaniu wiadomosci to polaczenie zamykac ?

[mystery]

Sugeruję raczej użyć czegoś, co nie tworzy żadnego połączenia, jak UDP. Nigdy nie pisałem komunikatora, ale wydaje mi się, że nie działają one na zasadzie utrzymywania połączenia dla każdego okna rozmowy. Serwer nie powinien tracić swoich zasobów na utrzymywanie każdej sesji. Powinien raczej po prostu przekazać otrzymaną wiadomość dalej. Wyobraź sobie kilka milionów userów, którzy w tej samej chwili rozmawiają z kilkoma osobami. Wydaje mi się, że serwer po jakimś czasie odmówiłby przyjmowania nowych połączeń, ze względu na to, że zarezerwował już swój limit. Taka sytuacja jest niedopuszczalna.

Socket z kolei (lub datagram UDP) po prostu wysyłasz i to wszystko. Serwer odbiera pakiet, patrzy komu wysłać i wysyła. Żadnego połączenia nie trzeba utrzymywać, a serwer poradzi sobie nawet z wielkim ruchem, gdyż obsłużenie jednej wiadomości zajmie mu kilka ms, a mało prawdopodobne jest, że n wiadomości nadejdzie w tej samej ms. Nawet jeśli tak by się stało to mechanizm kolejkowania (który powinien być zaimplementowany) sobie z tym poradzi.

 

Jednak mogę się mylić, gdyż jak już wspomniałem wcześniej, nigdy nie pisałem komunikatora. Pisałem natomiast grę wieloosobową w Javie i korzystałem z socketów wtedy. Nie pamiętam tylko w jaki sposób z nich korzystałem. Czy tworzyłem połączenie, czy na datagramach leciało. Dawne czasy :)

 

pozdrawiam

m

[azyl]

Zgadzam się z tym co mówisz, jednak ten scenariusz się sprawdza w przypadku kiedy klient wysyła wiadomość do zdalnego serwera a ten przesyła ją do klienta docelowego, czyli klient -> serwer -> klient.

Ja natomiast staram się napisać komunikator typu klient serwer bez serwera zdalnego. Tzn serwer bezpośrednio łączy się z klientem i przesyłają między sobą wiadomości.

W sumie zastanawiam się nad wybraniem pierwszej opcji, czy nie zrobić stałego serwera i tylko dorobić do niego klientów. Tylko nie wiem jak wtedy miałbym adresować wiadomość, żeby trafiała do konkretnego klienta. Teraz podaje ip i port, na którym ma się łączyć klient z serwerem i następuje połączenie.

[moe]

czemu nie szukasz na googlach? przeciez jest masa projektow, ktore udostepniaja kod zrodlowy a nawet jakies tutoriale od 0

[azyl]

Szukam w googlach, ale nie potrzebuje gotowego rozwiązania tylko pomysł, podpowiedź. To jest praca na studia i nie mogę tu walnąć gotowego przykładu z googli.

[moe]

nikt Ci przeciez nie kaze kopiowac gotowca - wazne ze masz przyklad z czego to korzysta i jak mniej wiecej wyglada.

[Gość]

Zrobilem wstepny projekt laczenia sie za pomoca TCP, jednak nie dziala tak jak powinien. Kiedy wysle wiadomosc z klienta do serwera, nie moge nic zrobic jesli nie zamkne polaczenia. Nie ma wiec mowy o wyslaniu nastepnej wiadomosc czy odebrania wiadomosc od serwera bo program sie wiesza.

A jakis kod moze? Na czym sie wiesza dokladnie, za malo szczegolow...

 

Czy ja popelniam blad czy tak dziala protokol TCP ?

Wiem, ze mozna zrobic komunikator na socketach, jednak chce sie najpierw upewnic czy tcp definitywnie odpada, bo mam w nim juz troche kodu napisanego.

 

Tez nie pisalem zadnego komunikatora, ale jestem przekonany, ze wiekszosc dziala na TCP. Pytanie tylko czy polaczenie jest trzymane przez caly czas rozmowy (jak to okreslic? do zamkniecia okienka od tej osoby moze..) albo za kazdym razem na nowo po kazdej wyslanej w.... nie, to niemozliwe.. raczej obstawiam, ze "kanal" jest otwarty caly czas (z jakims timeoutem rzecz jasna) i jest dwukierunkowy.

Na przykladzie GG to jest pewnie tak, ze najpierw laczy sie z serwerem i "dowiaduje" czy osoba, do ktorej chcesz cos napisac jest "widoczna" z zewnatrz czy ukryta za NAT'em bez przekierowan. Jesli to drugie, a z kolei Ty masz komputer, do ktorego mozna sie podlaczyc z internetu to tamta osoba otwiera kanal do Ciebie, ale on i tak jest dwukierunkowy, wiec to nie gra wiekszej roli kto go utworzyl.

UDP odpada z prostego wzgledu.. jest jak Poczta Polska.. po wyslaniu zwyklego listu (pakietu) nikt nie wie gdzie on jest i moze zginac w trasie a Ty sie o tym nawet nie dowiesz. TCP jest bardziej jak kurier.. gwarantuje dostarczenie przesylki (pakietu) a jesli sie to z jakis przyczyn niezaleznych nie uda to zostaniesz o tym powiadomiony i bedziesz mogl podjac stosowne kroki (np. ponowna proba).

UDP jest typu fire & forget, wykorzystywany m.in. do gier, bo jest troszke szybszy niz TCP, wiec ping moze byc mniejszy, a tragedii nie ma jak sie 1 czy 2 pakiety gdzies zawierusza.. chyba, ze zgubi sie wiecej pod rzad, to wtedy pojawia sie ladna wtyczka i kazdy pisze na konsoli "LAG!!!" :)

W przypadku komunikatorow nie mozna sobie pozwolic na taka nonszalancje, klient musi miec pewnosc, ze wiadomosc doszla do odbiorcy albo, ze nie udalo sie jej w ogole wyslac. Tutaj nie ma miejsca na packet losty. No chyba, ze ktos taka kontrole transmisji chce zaimplementowac na poziomie aplikacji, ale po co, skoro po to wlasnie jest TCP.

 

Edit: sprawdzilem wlasnie Skype'a.. jest tak jak myslalem, polaczenie jest tworzone przy napisaniu pierwszej wiadomosci, nie znika po zamknieciu okienka (po obu stronach), wiec pewnie jest cachowane, dopiero po kilku minutach samo "zgaslo".

Edytowane 13 Kwietnia 2010 przez FiDO