[C] recv socket.

[Verwijderd]

Ik heb een vraag over de recv functie voor de sockets in C.

Ik gebruik C als server en java als client.

In C worden allemaal sensor waardes uitgelezen en die moeten in java weer te zien zijn. Ik moet vanuit de java client de min en max waardes voor een sensor veranderen en die dan versturen naar de C server.

Er wordt gebruik gemaakt van de functie recv in de C server. Het punt waar ik mee zit is dat de recv functie van C blijft wachten op een aanvraag van de java client maar ik wil wanneer er niks binnen komt dan moet hij gewoon weer verder met uitlezen van de sensoren.

Ik weet dat ik in java natuurlijk een 0 kan versturen zodat de C server weer verder kan. Alleen ik wil de dataverkeer zo minimaal houden.

Is er een oplossing dat de recv functie in C maar een paar miliseconden wacht op een aanvraag zodat hij weer verder kan.

Op internet heb ik wel iets gevonden maar dat gaat alleen over wanneer de socket gedisconnect zijn.

[matthijsln]

Je kan non-blocking sockets gebruiken of select() of poll().

Dit kan je trouwens in praktisch elke documentatie over sockets vinden.

[CyBeR]

select() of poll() zijn het simpelst. Die geef je gewoon een lijst sockets met eventueel een timeout en dan wacht 'ie zo lang je wil op data en als dat er is krijg je de socket waar 't om ging terug. Als dat niet gebeurde komt de timeout langs en kun jij doen wat je moet doen om vervolgens weer opnieuw te beginnen.

[MikeN]

Wat matthijsln zegt. Zie http://www.gnu.org/s/libc...Getting-File-Status-Flags voor een voorbeeldje van het zetten van de nonblocking flag op een socket, je recv() zal dan direct returnen met een EWOULDBLOCK error conditie als er geen data is.

http://www.gnu.org/s/libc.../Waiting-for-I_002fO.html voor een voorbeeld van select(). Eea is wel afhankelijk van het OS wat je gebruikt volgens mij :-)

[CyBeR]

select() is op zich gewoon POSIX, wat inhoudt dat 't redelijk cross-platform is, zeker qua UNIX maar ook Windows NT is gedeeltelijk POSIX-compliant. poll() is niet echt standaard.

[matthijsln]

En natuurlijk bij non-blocking i/o wel opletten dat je niet gaat busy-waiten , dus zoals CyBeR zegt zou ik gaan voor select() die het simpelst is.

[ Voor 20% gewijzigd door matthijsln op 13-08-2009 00:10 ]

[.oisyn]

Of je checkt met ioctl() (of ioctlsocket() onder Windows) met de FIONREAD optie hoeveel bytes er in de receive buffer staan.

[Verwijderd]

Het is me gelukt alleen nu zit ik met een ander probleem.

Ik gebruik deze code om gegevens te versturen vanuit C naar java:

send(commSocket, msg, strlen(msg), 0);

En in mijn java vang ik het op met:

BufferedReader br = new BufferedReader(new InputStreamReader(socket.getInputStream()));
while ((str = br.readLine()) != null) {
System.out.println(str);

Het probleem waarmee ik zit is dat het ontvangen van gegevens in java pas gebeurt wanneer de C server ermee stopt en niet wanneer de send functie wordt aangeroepen.

Op internet heb ik gezocht maar daarin heb ik alleen kunnen vinden dat het wel moet werken. Zelf dacht ik dat het kon liggen aan de buffer en toen heb ik send naar sendall veranderd. Alleen sendall staat niet gedefineerd in de header file (socket.h) van cygwin.

[ Voor 5% gewijzigd door Verwijderd op 14-08-2009 01:28 ]

[CyBeR]

Hoe groot is je message? Zit er een newline achter? Dit soort dingen wil wel 's achtergehouden worden tot er een packet vol gepropt kan worden. In dat geval, kijk even naar TCP_NODELAY.

[Verwijderd]

dit is 1 string die verstuurd moet worden:
Sensor01#10#10#10#10-Sensor02#20#20#20#20-Sensor03#30#30#30#30-Sensor04#40#40#40#40-Sensor05#50#50#50#50-Sensor06#60#60#60#60-Sensor07#70#70#70#70-Sensor08#80#80#80#80

Als ik die TCP_NODELAY erbij zet doet hij nog steeds hetzelfde.

send(commSocket, msg, strlen(msg), TCP_NODELAY);

[ Voor 11% gewijzigd door Verwijderd op 14-08-2009 02:12 ]

[CyBeR]

TCP_NODELAY zet je met setsockopt().

http://www.unixguide.net/network/socketfaq/2.16.shtml

[H!GHGuY]

Het kan ook wel eens aan die BufferedReader liggen toch?

Je doet daar readLine() terwijl ik niet echt een carriage-return/linefeed zie in je string...

[Verwijderd]

Maar wat kan ik dan i.p.v readLine opschrijven.

[H!GHGuY]

Ofwel zend je na elke sensor readout een end-of-line marker mee, ofwel gebruik je geen bufferedreader maar de niet-buffering component om dan stukjes uit te lezen.

Optie 1 is veruit het makkelijkst.

[CyBeR]

H!GHGuY schreef op vrijdag 14 augustus 2009 @ 07:46:
Het kan ook wel eens aan die BufferedReader liggen toch?

Je doet daar readLine() terwijl ik niet echt een carriage-return/linefeed zie in je string...

Goed punt, was me nog niet opgevallen.