Dnia 2011-04-15, pią o godzinie 13:55 +0200, Rafał Malinowski pisze:
Mam pewien problem z opisem protokołu :) Konkretnie z tym działem:
http://toxygen.net/libgadu/protocol/#ch3.4 i z opisem przeplatanki
GG_DCC7_INFO z pobieraniem adresu serwera pośredniczącego.
Jeżeli dobrze rozumiem, to w tym momencie libgadu powinno wykonywać
równocześnie 2 połączenia:
- na głównym sockecie wysłać informacje na temat GG_DCC7_INFO
- na nowo otwarytym sockecie DCC łaczyć się z relayem i odebrać adres serwera?
Próbowałem wczoraj to zaimplementować, jednak nie rozumiem jeszcze
zbyt dobrze kodu libgadu i nie wiem jak otworzyć równocześnie drugie
połączenie. Być może należałoby to rozwiązać w ten sposób, że po
wysłaniu GG_DCC7_INFO powinienem otworzyć nowy socket DCC i odebrać
relaya i przekazać go jako DCC_PENDING do klienta (Kadu), żeby on już
sobie na nim gg_dcc7_watch_fd robił?
Niestety obsługa DCC7 w oryginalnym kliencie się trochę skomplikowała.
Kiedyś wyglądało to mniej więcej tak, że jedna strona najpierw otwierała
gniazdo, wysyłała GG_DCC7_INFO i czekała na połączenie. Druga strona po
otrzymaniu adresu i portu próbowała się połączyć, ale jeśli się nie
udało, to sama otwierała gniazdo i wysyłała do inicjującego. Dopiero
jeśli to się nie udało, zaczynało się połączenie przez serwer.
Z tego co widzę, teraz obie strony od razu otwierają gniazda, wysyłają
GG_DCC7_INFO _oraz_ zaczynają gadanie z serwerem pośredniczącym. Nie
pasuje to w ogóle do architektury libgadu, gdzie jedno połączenie rządzi
jednym deskryptorem. Powoduje to problemy w komunikacji libgadu z GG10,
gdy libgadu najpierw wysyła GG_DCC7_INFO z namiarami na otwarty port,
ale gdy otrzyma te informacje od drugiej strony, zamyka swoje gniazdo i
łączy się z podanym. GG10 czasami pokazuje, że połączenie anulowano,
co wygląda na wyścig związany z zamykaniem gniazda, z którym GG10
zdążyło się już połączyć. Jeśli do tego jeszcze dodać połączenie przez
serwer... robi się trochę skomplikowanie.
Macie może jakieś pomysły jak to rozwiązać w inny sposób niż dodanie
pól .fd2 i .fd3 w strukturze gg_dcc7? ;) Wcześnie myślałem o tym, żeby
po otrzymaniu GG_DCC7_INFO nie zamykać lokalnego gniazda, ale do .fd
wrzucić deskryptor połączenia do drugiej strony z timeout = 1 i
soft_timeout = 1, co pozwoliłoby nam z sekundowym opóźnieniem obsłużyć
połączenia przychodzące. Tyle, że trzymanie się API na siłę takim
kosztem chyba nie ma sensu.
Pozdr,
Wojtek
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
