Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #33262
| 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> |
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
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