15. august 2005 - 21:41Der er
15 kommentarer og 1 løsning
2 x read på socket giver problemer.
Hejsa alle, Jeg står med følgende kode (jeg har renset lidt ud i den - fjernet nogle løkker der indlæser resulterne osv. burde ikke have nogen betydning for problemet):
memset(buf,'\0',sizeof(buf));
// Direct stream status - send request to switch device strcpy(command,"session direct stats show"); send_command(sd,peer,command);
// Resetting counter used when reading stats from switch device ix = 0;
// Looping as long as there is something to read while((recv_status = recv(sd, buf+ix, sizeof(buf)-ix-1, 0)) > 0){ ix = ix + recv_status; }
if(recv_status == -1) perror("Socket");
// Parses the result extract_stats_data(buf, data, 0);
// For the direct stream the result is stored in the first struct ... kode der gemmer resultater ...
// Sendt reset to switch device strcpy(command,"session direct stats reset"); send_command(sd,peer,command);
// reset the buffer memset(buf, '\0', sizeof(buf));
// Broadcast stream status - send request to switch device strcpy(command,"session bc stats show"); send_command(sd, peer, command);
// Resetting counter used when reading stats from switch device ix = 0;
// Looping as long as there is something to read while((recv_status = recv(sd, buf+ix, sizeof(buf)-ix-1, 0)) > 0){ ix = ix + recv_status;
printf("BYTES LAEST: %d\n", recv_status); }
if(recv_status == -1) perror("Socket");
// Parse the recived data from the switch device extract_stats_data(buf, data, 1);
... kode der gemmer resultater ...
}
// Sendt reset to switch device strcpy(command, "session bc stats reset"); send_command(sd, peer, command);
fflush(stdout);
Koden gør følgende: 1. Sender en forespørgsel på data direkte fra server 2. Læser resultatet 3. Sender en forespørgsel på data fra andre klienter (broadcast) 4. Læser resultatet
Problemet viser sig på følgende måde:
1. Køres den første while loop der læser, kommer vi aldrig ind i nr.2 2. Køres de to while loops hver for sig (dvs. med den ene udkommenteret) kører det fint.. 3. Køres kun den sidste læse-while-loop altså jeg sender begge forespørgsler til vores switch device før jeg læser får jeg fint resultatet fra begge forespørgsler tilbage..
Jeg har før haft problemer med at sende flere forespørgsler til en socket lige i træk.. Er der noget jeg skal være opmærksom på her? Den socket jeg prøver at læse fra er sat til non-blocking.
Her er foresten koden der sender forespørgslen (funktionen send_command):
void send_command(int sd, struct sockaddr_in peer,char *command) { int send_status;
Grunden til jeg har lavet det så den læser mere end en gang - er at jeg vil være sikker på at få hele resultatet.. Jeg kunne som du siger også læse til jeg har en eller anden form for terminering af input..
Jeg tror jeg laver det om så jeg sender begge forespørgsler og så læser hele resultatet en gang.. Det ser nemlig udtil at virke..
En af problemerne er også lidt, at selvom jeg laver den blocking. Vil den aldrig stå og vente på input, da der altid (næsten) bliver smidt 4 bytes tilbage - så læser den bare dem og er videre..
Og da jeg havde den på blocking og ikke havde recv inde i en while - fik jeg tit kun dele af resultatet.. Resten kom så senere i næste læsning..
Jeg forstår bare ikke helt hvad der kan går galt..
- Jeg sender en forespørgsel - Jeg læser resultatet til der ikke er mere - Jeg sender en ny forespørgsel - Jeg prøver at læse resultatet, men da vi ikke kommer ind i den sidste læse-while løkke må det være fordi der ikker er noget at læse..
Udkommenteret hver for sig virker det.. Men kun en læsning virker det.. Hvorfor må jeg ikke læse det første resultat og derefter det næste - hvad kan der være galt i det??
Jo, det ser det faktisk ud til.. jeg fatter det ikke - jeg sender jo først nr2 forespørgsel efter jeg har lavet den recv (som faktisk ser ud til at få begge resultater)..
ja - har lige testet det hvis jeg udskriver det jeg læser i første recv - er begge resultater der.. Jeg er virkelig lost her - hvordan kan det lade sig gøre??
Arne, jeg har fundet problemet ... der skulle simpelthen et timedelay ind - mellem send_command og recv kaldene.. nu virker det fint.. Den var simpelthen kommet bagefter med svarne på vores forespørgsel..
Jeg kan dog ikke så godt lide sådan nogel time-delay løsninger.. kender du nogle andre muligheder..
At lave socket'en blocking har desværre ingen effekt - da der jo næsten altid kommer de 4 byte..
Problemet var tilsyneladende at vi sende forespørgslerne for hurtigt, switch-devicen nåede simplethen ikke at svare.. jeg kunne se det ved at ligge et lille time-delay ind mellen send_command og recv kaldene..
Jeg ville gerne undgå den slags manuelle time-delays, men har ikke fundet på noget endnu..
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.