Hi Guy
Rafi Cohen wrote: > Hi, as a pproject for a company I'm writing a tcp/ip application on > linux using C language. ah welcome, welcome to the pleasure dome... Hmm, thanks for your "warm" greetings. > My application has 2 connections as client to remote servers and is by > itself a server "accepting" remote client connections. > I'm using select() mechanism to manage all those connections. Everyting > works nicely until any of the remote sideds disconnects. > In some of such cases, I'm not succeeding to reconnect to this remote as > client or re-accept connection from tjhe remote client. you're not describing things properly here, since later you say you are not managing to disconnect (the problem is not with re-connecting - which, if happened, would imply a different problem altogether) You are correct, what I indeed meant to say is in order to re-connect, first I need to disconnect propperly and here lies my problem. > Reading some documentation on tcp/ip programming, I had the impression > that the select mechanism should detect such remote disconnect event, > thus enabling me to make a further "read" from this socket which should > end in reading 0 bytes. Reading 0 bytes should indicate disconnection > and let me disconnect propperly from my side and try to reconnect. > However, it seems that select does not detect all those disconnect > events and even worse, I can not see any rule behind when it does detect > this and when it does not. select does not notice "disconnections". it only notices if the socket was closed by the remote side. that's a completely different issue, and that's also the only time when you get a 0 return value from the read() system call. Yes, this does make sense and I need to check with the software developer to which mine is connecting remotely, if he indeed "closes" the socket when disconnecting. You gave me a clue, thanks. > So, I have a couple of questions and I'll most apreciate any > assistance. 1. Would you confirm that select, indeed, does not detect > each and every remote disconnection and do you know if there is a rule > behind those cases? TCP/IP stacks on linux, by default, will only notice a network disconnection (i.e. the network went down) "reliably" after 2 hours. that's how TCP/IP's internal keep alive mechanism is set. 2 hours is a completely impractical value for any sane system you might develop. you can tweak this parameter of the TCP/IP stack for specific sockets, on current linux kernels, using a socket option. (man 7 tcp - and look for 'keepalive' - there are 3 parameters for this). i never used this mechanism, since it was only possible to make this change globally when i needed that. I know of this option and will look into that deeper. May be I miss here something, but this option may be relevant for the case my application is a server. I wonder how it would affect, if at all, when my application is a client. > 2. If I need to detect those disconnections to react propperly in my > application and I can not rely on select, what would you suggest me to > do? should I use a kind of "ping" mechanism to check every some seconds > if the connection is still "alive"? or may be use multithread instead of > select, where each thread is responsible for each connection source and > instead of select I loop on read from this source and so, can detect > when I read 0 bytes, which is the disconnect indication and react > accordingly? read would fail just like select does, and because of the same reason. you could implement the keepalive in your application, in case the keepalive parameters tweaking of the TCP stack does not work, for some reason. --guy Thanks, Rafi. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.0/803 - Release Date: 5/13/2007 12:17 PM ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
