socket timeout

Jeg ved ikke om man kan sætte en timeout på, men ellers kan du starte en ny tråd, lade den prøve at connecte og checke fra din hovedtråd, om det lykkedes...

og så lave "kill" af tråden hvis den ikke bliver færdig inden for den ønskede timeout grænse.

TClientSocket og TServerSocket componenterne i BCB *har* en timeout property, men om de har implementeret det vha. tråden, eller der findes en i de alm. socket API'er ved jeg ikke.

brug select()
Du sætter din socket i non-blocking mode (f.eks. med ioctl()) og så åbner din forbindelse. Så kalder du select med en timeval på det ønskede antal ms og tjekker for skrivbarhed eller læsbarhed af din socket, afhængigt af om du skal sende noget til din server først eller omvendt. Hvis select giver 0, er der opstået timeout og du kan derfor kalde close() på din socket.

stringbuffer >> Nå på den lumske (dog simple) måde !

// er da ikke lumsk *G*

En anden ide er bruge TCP's indbyggede keep-alive på socket. Det kan sættes når socket'en oprettes.

tuxic >> "Dør" socket'en så efter n sekunder (sat som keep-alive), hvis den ikke har fået noget svar ?

Det svarer til at den anden side lukker forbindelsen. Husk at SO_KEEPALIVE bruger en default timeout før en keepalive-probe sendes på MINDST 2 timer. Jeg ved ikke hvordan man kan stille på dette interval, måske kan man gøre det med sysctl, så bliver det bare for alle forbindelser.... hvis det er BSD-lignende OS, er der måske en kerneparameter, der hedder tcp_keepidle eller sårn..

ezrider <- Jeg har vist misforstået spørgsmålet, troede at det var timeout på connect(), du ville lave, men det er åbenbart mere tjekke status for en åben forbindelse.

En løsning kan være at sende f.eks. tomme requests (linieskift-tegn eller lign.) til din server med nogle minutters mellemrum eller hvad det nu skal være. Hvis forbindelsen er blevet brudt får du en SIGPIPE, som du så kan handle.

stringbuffer >> Dermed har du dine keepalive meddelelser og inddirekte derved også timeout.

Hvis det dog kun er til at se om maskinen er i live, ville det da ikke være bedre bare at pinge den?

Problemet er vel at programmet skal forsøge connect til serveren i et (kortere) stykke tid - derefter opgive. Her kunnet ping vel være en udemærket løsning, hvis man kan checke resultatet af den - så kan man det ? (Og er det så ikke svaret på dette spørgsmål.)

Selvfølgelig kan man det, her er et eksempel på et lille "ping" program, fandt den via google: http://www.linuxsocket.org/books/Sockets/programs/part4/chap18/myping.c

Ifølge:
http://www.remote.org/jochen/mail/popular/doc/html/tcp-keepalive.htm
kan man på Linux-systemer sætte Keep-Alive timeout'en i:
/proc/sys/net/ipv4/tcp_keepalive_time
Det er så en system wide setting. Ifølge TCP-specificationen kan man sætte tcp på socket niveau (og det kan man oxo i .NET fx). I windows kan man oxo sætte det på NIC-niveau.
Det er korrekt at default er 2 timer, men det kan man jo bare stille på.
Bemærk, at det er overlegent i forhold til ping. ping fejler jo hvis maskinen er død, men ikke hvis det bare er den anden af socket'en der er død.
200 ms forekommer desuden at være kort tid, men ok det er jo bare min (forblommede?) ide.
HTH

ok, jeg er vist lidt kortfattet:
Bemærk, at keep-alive er overlegent i forhold til ping. ping fejler jo hvis maskinen er død, men ikke hvis det bare er den anden ende af socket'en der er død.

Når man ikke får en ICMP echo reply så ved man da at maskinen er død?
Og ja, 200 ms er nok ALT for kort tid... selv med keepalive skaber det nok en vis belastning af de to maskiners protokolstakke.

>Når man ikke får en ICMP echo reply så ved man da at maskinen er >død?
Præcis. Det er derfor at det er bedre at bruge keep-alive. Det kan jo tænkes at server programmet er gået ned, men at maskinen stadig svarer på ping requests.