Aplikacja Server i Client

[polymorphism]

Baron, użycie timera, pomimo że jest lepszą opcją, nic tu nie da, bo kolega nie wie, jak działają sockety. A działają tak, że jeśli socket nie będzie miał odebranych danych w buforze, będzie blokował. W przypadku ReadLn będzie blokował do momentu, gdy nie odbierze całej linii tekstu lub nastąpi tzn. timeout. Problem w tym, że nie zawsze wiadomo kiedy serwer wyśle taką linię, więc trzeba by jakoś sprawdzać, czy w sockecie są jakieś dane. W winsocku jest funkcja select, która znakomicie się do tego nadaje, no ale mamy tu do czynienia z INDY, więc trzeba by znaleźć jakiś ekwiwalent tej funkcji.

____
p.s. a to loginUser to po co?

[Bert1223]

ShowMessage() był tylko dla testu czy to w ogóle działa, co do loginUser to zmienna bool i jeżeli użytkownik zalogował się pomyślnie wartość zmieniana jest na 1.

[polymorphism]

(...) co do loginUser to zmienna bool i jeżeli użytkownik zalogował się pomyślnie wartość zmieniana jest na 1.

Tylko pytanie, po co? Przecież jeśli klient nie zalogowałby się, to serwer nie powinien z nim w ogóle nawiązywać jakiegokolwiek kontaktu, poza prośbą o zalogowanie. Już pomijam fakt, że sam warunek jest dziwnie skonstruowany. Sensowniej jest tak:

Kod: Zaznacz cały

void __fastcall TForm3::ApplicationIdle(TObject *Sender, bool &Done)
{
   if(!loginUser)return;
   
   /* tu ReadLn i cała reszta */
}

Choć według mnie użycie loginUser jest zbędne i wynika z nieprzemyślanego protokołu, pisanego na hurra!. Nie jestem pewny, czy dobrym pomysłem jest, żeby serwer sam z siebie wysyłał coś klientowi. Według mnie lepszym rozwiązaniem byłby schemat: klient pyta serwer odpowiada, uprości to wiele spraw.

---

Kod: Zaznacz cały

String line = "";

To przypisanie pustego stringa jest zupełnie pozbawione sensu.

[Cyfrowy Baron]

Baron, użycie timera, pomimo że jest lepszą opcją, nic tu nie da, bo kolega nie wie, jak działają sockety.

Nie upieram się przy Timer'ze, gdyż nie wydaje mi się by był dobrym rozwiązaniem, dla tego co autor wątku próbuje osiągnąć, chyba żeby umieścić Timer w wątku. Po prostu udzieliłem odpowiedzi na pytanie i wskazałem alternatywę dla zdarzenie OnIdle.

---

Nie jestem pewny, czy dobrym pomysłem jest, żeby serwer sam z siebie wysyłał coś klientowi.

Właściwie to klient powinien wysłać do serwera jakieś żądanie i serwer dopiero odpowiada. Takie rozwiązanie nie wymaga ani wątków, ani zegara, gdyż z tego co jeszcze pamiętam o socketach - a mogę się mylić - to po podłączeniu do klienta będą one nasłuchiwały i oczekiwały na komunikaty od klienta. Tak to przynajmniej zrobiłem w kursie praktycznym - prosty komunikator sieciowy. Jest to program dość prosty i nie pozbawiony błędów, ale nie ma tam żadnych pętli, wątków ani Timer'ów, a mimo klient może się komunikować z serwerem.

[polymorphism]

Nie upieram się przy Timer'ze (...)

Odniosłem wrażenie, że źle odebrałeś moją wypowiedź. Ja tam nie podważam tego, co napisałeś odnośnie timera. Jedynie zwróciłem uwagę, że użycie timera nie rozwiąże problemu blokowania aplikacji, ponieważ problem leży w nieodpowiednim użyciu socketów.

Właściwie to klient powinien wysłać do serwera jakieś żądanie i serwer dopiero odpowiada.

W sumie to napisałem to samo po zdaniu, które cytowałeś...

---

A propos funkcji select i jej odpowiednika w INDY, jest metoda TIdIOHandler::Readable, która wygląda na to, że jest tym, czego szukamy.

Czyli mogłoby to wyglądać tak:

Kod: Zaznacz cały

void __fastcall TForm3::ApplicationIdle(TObject *Sender, bool &Done)
{
   if(!TCPClient->Socket->Readable(1))return;

   String line = TCPClient->Socket->ReadLn();

   (...)
}

Oczywiście strzelam, bo nie znam tej biblioteki, jedynie opieram się na dokumentacji, ale nie powinno być problemów...