Wymiana danych pomiedzy socket`ami ( funkcja RECV() i SEND()) - pilne :(

[news]

Witam

Chicialbym na lamach grupy dyskusyjnej poruszyc temat gniazdek sieciowych
nad ktorym glowie sie od jakiegos juz czasu.
Napisalem klienta na platformie AS/400 ( w jezyku ANSI C ) ktory wywoluje
polaczenie do Serwera napisanego na platformie Windows XP ( w jezyky VC++
6.0).
W ramach tego polaczenia opracowanym protokolem ( w modelu OSI to bedzie
chyba 'protokol aplikacji ;)) przekazuje dane ( kody produktow, ceny,
ilosci...etc...) do serwera po stronie Windowsa.
Serwer odbiera i formatuje odpowiednio przekazujac to na drukarke fiskalną.
Transmisja pomiedzy klientem a serwerem dziala w oparciu o funkcje sieciowe
send(), recv(), gniazdko jest skonfigurowane w kliencie w trybie blokujacym
na serwerze zas dzialaja w oparciu o MFC ( komunikaty systemu Win.):

Gdy klient wysyla send() wtedy serwer wykrywa to zdarzeniem OnRecv() w
tej metodzie rozpoznaje poszczegolne sekwencje protokolu, rpozpoznaje je i
odroznia od danych....etc...

Schemat klarowny i prosty ale niestety nie funkcjonuje tak jakbym sobie tego
zyczył.
Mianowicie kiedy klient wysle jakis lancuch np: 256 bajtów - serwer dobiera
odsyła potwierdzenie odbioru.
Tutaj pojawia sie problem funkcja recv() od klienta ustawiona w trybie
blokowym czeka i nie moze sie doczekac na odpowiedz od serwera.
Dopiero napisana funkcja Timeout() zwlania ten socket po uplywie jakiegos
czasu.
Sytulacja jest o tyle dziwna ,ze nie ma jakiejs logicznej zaleznosci (a moze
jest tylko ja nie potrafie ja wysledzic) wszystko dziala jak nalezy, a raz
na jakis czas powstaja "zwisy" na funkcji recv() (strona klienta).
Czego to moze byc wina , czy stos TCP ma tutaj jakies znaczenie, czy powinno
sie go jakos czyscic,zerowac...a moze to wina czegos innego?


Pozdrawiam i czekam na jakas sugestie , podpowiedz od Was.

Maciek

[Sektor van Skijlen]

Post by news
Witam
Chicialbym na lamach grupy dyskusyjnej poruszyc temat gniazdek sieciowych
nad ktorym glowie sie od jakiegos juz czasu.
Napisalem klienta na platformie AS/400 ( w jezyku ANSI C ) ktory wywoluje
polaczenie do Serwera napisanego na platformie Windows XP ( w jezyky VC++
6.0).
W ramach tego polaczenia opracowanym protokolem ( w modelu OSI to bedzie
chyba 'protokol aplikacji ;)) przekazuje dane ( kody produktow, ceny,
ilosci...etc...) do serwera po stronie Windowsa.
Serwer odbiera i formatuje odpowiednio przekazujac to na drukarke fiskaln?.
Transmisja pomiedzy klientem a serwerem dziala w oparciu o funkcje sieciowe
send(), recv(), gniazdko jest skonfigurowane w kliencie w trybie blokujacym
Gdy klient wysyla send() wtedy serwer wykrywa to zdarzeniem OnRecv() w
tej metodzie rozpoznaje poszczegolne sekwencje protokolu, rpozpoznaje je i
odroznia od danych....etc...
Schemat klarowny i prosty ale niestety nie funkcjonuje tak jakbym sobie tego
zyczył.
Mianowicie kiedy klient wysle jakis lancuch np: 256 bajtów - serwer dobiera
odsyła potwierdzenie odbioru.
Tutaj pojawia sie problem funkcja recv() od klienta ustawiona w trybie
blokowym czeka i nie moze sie doczekac na odpowiedz od serwera.
Dopiero napisana funkcja Timeout() zwlania ten socket po uplywie jakiegos
czasu.

Z tego, co ja się orientuję, to taka sytuacja może wystąpić wtedy, gdy
wysyłający buforuje dane. Dane nie są wysłane, bo jeszcze czekają w buforze,
aż się zapełni. Może go nie opróżniasz?

Nie wiem, jak działa od tej strony MFC. Myślę, że gdybyś spróbował to zrobić
na surowo (przez select na przykład), to przynajmniej łatwiej byś ten problem
wyśledził (gdyby się pojawił).

[news]

Post by Sektor van Skijlen
Z tego, co ja się orientuję, to taka sytuacja może wystąpić wtedy, gdy
wysyłający buforuje dane. Dane nie są wysłane, bo jeszcze czekają w buforze,
aż się zapełni. Może go nie opróżniasz?

Mozesz mi przyblizyc ta kwestie ( jestem laikiem w programowaniu TCP ).

Post by Sektor van Skijlen
Nie wiem, jak działa od tej strony MFC. Myślę, że gdybyś spróbował to zrobić
na surowo (przez select na przykład), to przynajmniej łatwiej byś ten problem
wyśledził (gdyby się pojawił).

Nie uzywalem tej funckji w VC++ ale mysle ,ze nie bedzie problemu z
zaimplementowaniem tego tam.

Post by Sektor van Skijlen
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)gmail.com>
http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

[Sektor van Skijlen]

Post by news

Z tego, co ja się orientuję, to taka sytuacja może wyst?pić wtedy, gdy
wysyłaj?cy buforuje dane. Dane nie s? wysłane, bo jeszcze czekaj? w
buforze,
aż się zapełni. Może go nie opróżniasz?

Mozesz mi przyblizyc ta kwestie ( jestem laikiem w programowaniu TCP ).

To nie ma nic wspólnego z TCP. Normalnie funkcje do obsługi połączeń, czyli
write i read (lub send i recv; pod windowsem tylko te ostatnie) nie stosują
żadnego buforowania i gdybyś je stosował, nie miałbyś żadnego problemu.

Problem może stanowić co najwyżej MFC, które te dane być może jakoś buforuje.

[news]

Witam

Walsnie gdzies dorwalem funkcjie setsockopt(s, SOL_SOCKET, SO_RCVBUF, 1,
sizeof(SO_RCVBUF))
kotra zminia mi wilkosc przesylanego bufora.
1. Pytanie przy takim rozwiazaniu chcac np: przeslac 250 musialbym wukonac
send() w petli 250-ciu iteracji ?

2. Czy problem opisany w watku glownym ( zatykanie sie funckji recv()) mozna
by w jakis sposob rozwiazać standardowa funkcja jezyka
ANSI C fflush() - czyszczenie bufora?

Pozdrawiam

Maciek

[Sektor van Skijlen]

Post by news
Witam
Walsnie gdzies dorwalem funkcjie setsockopt(s, SOL_SOCKET, SO_RCVBUF, 1,
sizeof(SO_RCVBUF))
kotra zminia mi wilkosc przesylanego bufora.
1. Pytanie przy takim rozwiazaniu chcac np: przeslac 250 musialbym wukonac
send() w petli 250-ciu iteracji ?

Nie wiem. Nie używałem tego. Nie ustawiałem nic i działało dobrze.

Post by news
2. Czy problem opisany w watku glownym ( zatykanie sie funckji recv()) mozna
by w jakis sposob rozwiazać standardowa funkcja jezyka
ANSI C fflush() - czyszczenie bufora?

fflush działa na obiektach typu FILE. Nie ma to nic wspólnego z socketami.
Tzn. obiektów FILE można używać do obsługi socketów (przez utworzenie go
fdopen), ale te funkcje właśnie wprowadzają buforowanie - WŁASNE. Jeśli chodzi
nam o to, żeby buforowania nie było, to tym bardziej nie ma sensu stosować
tego rozwiązania.

[Krzysztof Rudnik]

Post by Sektor van Skijlen
fflush działa na obiektach typu FILE. Nie ma to nic wspólnego z socketami.
Tzn. obiektów FILE można używać do obsługi socketów (przez utworzenie go
fdopen), ale te funkcje właśnie wprowadzają buforowanie - WŁASNE. Jeśli

Ale czy to zadziala pod windows? Tak, zdaje sie uchwyty plikow i socketow
sa 'niekompatybilne'.

[Sektor van Skijlen]

Post by Krzysztof Rudnik

Post by Sektor van Skijlen
fflush działa na obiektach typu FILE. Nie ma to nic wspólnego z socketami.
Tzn. obiektów FILE można używać do obsługi socketów (przez utworzenie go
fdopen), ale te funkcje właśnie wprowadzają buforowanie - WŁASNE. Jeśli

Ale czy to zadziala pod windows? Tak, zdaje sie uchwyty plikow i socketow
sa 'niekompatybilne'.

No niestety nie bardzo zadziała. To jest niestandardowe i "na pewno" działa
tylko pod POSIX-ami.