Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #33262

Re: multithread client socket

From Martin Gregorie <martin@address-in-sig.invalid>
Newsgroups comp.lang.java.programmer
Subject Re: multithread client socket
Date 2015-12-01 22:04 +0000
Organization A noiseless patient Spider
Message-ID <n3l5gs$9v8$1@dont-email.me> (permalink)
References <75df5111-41b9-4833-8497-69104f011d14@googlegroups.com> <n3l1rl$sda$1@news.albasani.net>

Show all headers | View raw


On Tue, 01 Dec 2015 22:01:39 +0100, Jan Burse wrote:

> Philipp Kraus schrieb:
>> On large datasets the runtime cannot create new
>  > socket objects (socket already in use message). The Java client runs
>  > explicit socket.close without any error. My idea is, that each thread
>  > of the thread-pool holds a member with the socket,
>  > but I need must reconnect the client socket on each task, because the
>  > server closes the socket.
> 
> Its not necessarely the server that closes the socket.
>
Maybe so, but as Eric describes, given the way that POSIX socket handling 
works, the obvious way to write a server is to use this logic:

   Open a ServerSocket and listen for connections
   while (stillRunning)
   {
      Socket skt = ServerSocket.accept();
      while(stillConnected)
      {
         if (sktIsClosedByClient)
         {
            stillConnected = false;
            skt.close();
         }
         else
         { 
            read request from skt
            process the request
            write response to skt
         }
      }
   }

and it doesn't much matter whether the server is single or multi-threaded 
Java. Same goes for a server written in C, using poll() or select() and 
asynchronous i/o.
 
The only oddity I see is that Philip's server, which he seems to be 
saying already exists and is working so its behavior is a given, should 
close the socket after sending a response. 

The convention, in all the cases I've seen, is that the client is 
responsible for opening a session with the server and for closing it when 
the interaction is complete. This is good practise because it makes 
exception reporting easier (if the server closes the session it has a 
problem) and if a client can issue several requests its much more 
efficient to leave the session open until they've all been dealt with 
rather than starting a new session for each request.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

multithread client socket Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2015-12-01 09:36 -0800
  Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-01 11:58 -0800
    Re: multithread client socket Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2015-12-01 23:02 -0800
      Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-02 06:39 -0800
  Re: multithread client socket Jan Burse <janburse@fastmail.fm> - 2015-12-01 22:01 +0100
    Re: multithread client socket Jan Burse <janburse@fastmail.fm> - 2015-12-01 22:06 +0100
      Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-01 13:55 -0800
    Re: multithread client socket Martin Gregorie <martin@address-in-sig.invalid> - 2015-12-01 22:04 +0000
      Re: multithread client socket Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2015-12-01 23:04 -0800
        Re: multithread client socket Eric Douglas <e.d.programmer@gmail.com> - 2015-12-02 05:52 -0800
        Re: multithread client socket Martin Gregorie <martin@address-in-sig.invalid> - 2015-12-02 14:38 +0000
  Re: multithread client socket Arne Vajhøj <arne@vajhoej.dk> - 2015-12-05 20:00 -0500

csiph-web