<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Question on socket communication.... in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044278#M94087</link>
    <description>You are forking server processes listening for connections on a specified port. This won't work as the second child process will try to bind to the same port that is already in use by the first child process; owing to an established socket connection. This causes contention for the same port between the two child processes. I don't know your code but it might help if you included error checking into it to decipher the return codes from the bind, listen, and accept.&lt;BR /&gt;&lt;BR /&gt;~hope it helps</description>
    <pubDate>Thu, 26 Jul 2007 09:18:11 GMT</pubDate>
    <dc:creator>Sandman!</dc:creator>
    <dc:date>2007-07-26T09:18:11Z</dc:date>
    <item>
      <title>Question on socket communication....</title>
      <link>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044277#M94086</link>
      <description>Hi All,&lt;BR /&gt;&lt;BR /&gt;My application does the following:&lt;BR /&gt; &lt;BR /&gt;1. A process does socket, bind and listen. We have set SO_REUSEADDR and SO_REUSEPORT.&lt;BR /&gt;2. It then forks a child process.&lt;BR /&gt;3. The child process waits on accept on the original socket (that it inherited from the parent).&lt;BR /&gt;4. When a client connects to the ip/port, the child handles the communication (accept completes, then does send/recv).&lt;BR /&gt;5. Now I kill the parent (kill -9 &lt;PID&gt;)&lt;BR /&gt;6. I start the parent process again. It does the same socket, bind and listen with the same options as mentioned above.&lt;BR /&gt;7. Parent again forks a child process.&lt;BR /&gt;8. Child process waits on accept on the original socket (that is inherited from parent).&lt;BR /&gt;9. When a client connects to the ip/port, the second child does not get any connection, it is always the first child which is getting the connections.&lt;BR /&gt; &lt;BR /&gt;Why is this so that the second child does not get any connection ? Is this normal behaviour ? Are there any options that we are missing to set ?&lt;BR /&gt; &lt;BR /&gt;Thanks,&lt;BR /&gt;Subrat&lt;/PID&gt;</description>
      <pubDate>Thu, 26 Jul 2007 01:04:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044277#M94086</guid>
      <dc:creator>subrat chaudhary</dc:creator>
      <dc:date>2007-07-26T01:04:24Z</dc:date>
    </item>
    <item>
      <title>Re: Question on socket communication....</title>
      <link>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044278#M94087</link>
      <description>You are forking server processes listening for connections on a specified port. This won't work as the second child process will try to bind to the same port that is already in use by the first child process; owing to an established socket connection. This causes contention for the same port between the two child processes. I don't know your code but it might help if you included error checking into it to decipher the return codes from the bind, listen, and accept.&lt;BR /&gt;&lt;BR /&gt;~hope it helps</description>
      <pubDate>Thu, 26 Jul 2007 09:18:11 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044278#M94087</guid>
      <dc:creator>Sandman!</dc:creator>
      <dc:date>2007-07-26T09:18:11Z</dc:date>
    </item>
    <item>
      <title>Re: Question on socket communication....</title>
      <link>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044279#M94088</link>
      <description>You are doing this all wrong. You should be listening for connections on your dedicated port. You then fork() and the child establishes a connection using a port in the anonymous range and the parent goes back to listening for request on the dedicated port.</description>
      <pubDate>Thu, 26 Jul 2007 13:54:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044279#M94088</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2007-07-26T13:54:08Z</dc:date>
    </item>
    <item>
      <title>Re: Question on socket communication....</title>
      <link>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044280#M94089</link>
      <description>Hi:&lt;BR /&gt;&lt;BR /&gt;...and get out of the 'kill -9' habit.  Killing processes this way doesn't allow them to trap the signal and cleanup temporary files or shared memory segments.  (The failure to cleanup shared memory can be particularly harmful.  Try a 'kill -9' on your 'fbackup' sessions and watch your memory utilization climb!).  A 'kill -9' should be the 'kill' of last resort.  Start with a 'kill -hup' and then 'kill -term' and then lastly 'kill -9'.&lt;BR /&gt;&lt;BR /&gt;Regards!&lt;BR /&gt;&lt;BR /&gt;...JRF...</description>
      <pubDate>Thu, 26 Jul 2007 14:03:58 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044280#M94089</guid>
      <dc:creator>James R. Ferguson</dc:creator>
      <dc:date>2007-07-26T14:03:58Z</dc:date>
    </item>
    <item>
      <title>Re: Question on socket communication....</title>
      <link>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044281#M94090</link>
      <description>Replying on behalf of Subrat. Thanks a lot for your replies. Here are my comments:&lt;BR /&gt;&lt;BR /&gt;Sandman,&lt;BR /&gt;&lt;BR /&gt;Since there is usage of SO_REUSEPORT, we dont get error in bind and listen.&lt;BR /&gt;As soon as the first child (child of the first parent) is killed, the second child is able to receive requests.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;A Clay Stephenson,&lt;BR /&gt;&lt;BR /&gt;I didnt quite understand your explaination. &lt;BR /&gt;&lt;BR /&gt;Here is what we do:&lt;BR /&gt;&lt;BR /&gt;The child does the accept. The original socket (inherited from parent) is used in the accept call. Since we have set it as non-blocking, accept gives EAGAIN. We use select to get to know when the socket is ready for accept. When a client connects, the select completes telling that the socket is ready. The accept returns a new file descriptor. We use the new file descriptor for future communication (send/recv) and the original socket is again used to do the accept.&lt;BR /&gt;&lt;BR /&gt;So when the same logic is done in the second child (child of the second parent), we get EAGAIN in accept. We call select. When a client connects, the second child's select does not complete. We are interested in knowing the reason for this.&lt;BR /&gt;&lt;BR /&gt;Thanks,&lt;BR /&gt;&lt;BR /&gt;Shantanu...&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 26 Jul 2007 19:19:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/question-on-socket-communication/m-p/4044281#M94090</guid>
      <dc:creator>sjoshi</dc:creator>
      <dc:date>2007-07-26T19:19:38Z</dc:date>
    </item>
  </channel>
</rss>

