Reconnect socket without close/socket?

[Ian Pilcher]

I am writing a program that needs to read some data from a server via a
TCP socket every few seconds. (The server is the hddtemp program,
running in daemon mode.)

Documentation is somewhat sparse, but AFAICT the server simply accepts
connections, writes its output to the socket, and immediately closes it.
So every time I want to poll the server, I need to reconnect.

Is there any way to accomplish this without doing a close()/socket()
cycle every time? I've tried using shutdown(fd, SHUT_RDWR), but I get a
"Transport endpoint is already connected" error.

Thanks!

--
========================================================================
Ian Pilcher arequ...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[Jorgen Grahn]

On Thu, 2013-08-29, Ian Pilcher wrote:
> I am writing a program that needs to read some data from a server via a
> TCP socket every few seconds. (The server is the hddtemp program,
> running in daemon mode.)
>
> Documentation is somewhat sparse, but AFAICT the server simply accepts
> connections, writes its output to the socket, and immediately closes it.
> So every time I want to poll the server, I need to reconnect.
>
> Is there any way to accomplish this without doing a close()/socket()
> cycle every time? I've tried using shutdown(fd, SHUT_RDWR), but I get a
> "Transport endpoint is already connected" error.

And I guess this matters to you because you don't want to rework your
select(2) fd_set or whatever when the file descriptor changes?

It can't be about performance, because the connect() is what takes
real time, right?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Rainer Weikusat]

Jorgen Grahn <grahn...@snipabacken.se> writes:
> On Thu, 2013-08-29, Ian Pilcher wrote:
>> I am writing a program that needs to read some data from a server via a
>> TCP socket every few seconds. (The server is the hddtemp program,
>> running in daemon mode.)
>>
>> Documentation is somewhat sparse, but AFAICT the server simply accepts
>> connections, writes its output to the socket, and immediately closes it.
>> So every time I want to poll the server, I need to reconnect.
>>
>> Is there any way to accomplish this without doing a close()/socket()
>> cycle every time? I've tried using shutdown(fd, SHUT_RDWR), but I get a
>> "Transport endpoint is already connected" error.
>
> And I guess this matters to you because you don't want to rework your
> select(2) fd_set or whatever when the file descriptor changes?

Often, it won't: The original descriptor returned by socket was the
lowest-numbered free file descriptor at that time. If nothing else is
closed and re-opened, the number will say the same. Otherwise, dup2
could be used to avoid changing the descripor number when having to
deal with a new socket (instead of close(fd); fd = socket(...);, do
newfd = socket(...); dup2(newfd, fd); close(newfd);).

[Ian Pilcher]

On 08/29/2013 03:27 AM, Jorgen Grahn wrote:
> And I guess this matters to you because you don't want to rework your
> select(2) fd_set or whatever when the file descriptor changes?

It's more of an aesthetic thing. It just seems inelegant to be
repeatedly destroying and recreating the socket.

> It can't be about performance, because the connect() is what takes
> real time, right?

Definitely not about performance -- unless you put "efficiency" (for
some definition thereof) into that category.

Not a big deal; I was just wondering if there was a better way.

[Barry Margolin]

In article <%6LTt.232048$jW3....@fx23.iad>,

Ian Pilcher <arequ...@gmail.com> wrote:

> On 08/29/2013 03:27 AM, Jorgen Grahn wrote:
> > And I guess this matters to you because you don't want to rework your
> > select(2) fd_set or whatever when the file descriptor changes?
>
> It's more of an aesthetic thing. It just seems inelegant to be
> repeatedly destroying and recreating the socket.
>
> > It can't be about performance, because the connect() is what takes
> > real time, right?
>
> Definitely not about performance -- unless you put "efficiency" (for
> some definition thereof) into that category.
>
> Not a big deal; I was just wondering if there was a better way.

Sorry, no. Once a socket is disconnected, it's unusable.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Jorgen Grahn]

On Thu, 2013-08-29, Barry Margolin wrote:
> In article <%6LTt.232048$jW3....@fx23.iad>,
> Ian Pilcher <arequ...@gmail.com> wrote:
>
>> On 08/29/2013 03:27 AM, Jorgen Grahn wrote:
>> > And I guess this matters to you because you don't want to rework your
>> > select(2) fd_set or whatever when the file descriptor changes?
>>
>> It's more of an aesthetic thing. It just seems inelegant to be
>> repeatedly destroying and recreating the socket.
>>
>> > It can't be about performance, because the connect() is what takes
>> > real time, right?
>>
>> Definitely not about performance -- unless you put "efficiency" (for
>> some definition thereof) into that category.
>>
>> Not a big deal; I was just wondering if there was a better way.
>
> Sorry, no. Once a socket is disconnected, it's unusable.

Now that you mention it, it's not hard to find it documented.
In the Linux connect(2) man page:

Generally, connection-based protocol sockets may successfully
connect() only once; connectionless protocol sockets may use
connect() multiple times to change their association.

It doesn't say if this is Linux-specific or not; I suspect not.

[Ian Collins]

The Solaris wording is similar:

Generally, stream sockets can
successfully connect() only once. Datagram sockets can use

connect() multiple times to change their association.

Datagram sockets can dissolve the association by connecting
to a null address.

It also adds in the case of an error:

Applications should
close the file descriptor and create a new socket before
attempting to reconnect.

--
Ian Collins

[James K. Lowden]

On Thu, 29 Aug 2013 12:00:42 -0500
Ian Pilcher <arequ...@gmail.com> wrote:

> On 08/29/2013 03:27 AM, Jorgen Grahn wrote:
> > And I guess this matters to you because you don't want to rework
> > your select(2) fd_set or whatever when the file descriptor changes?
>
> It's more of an aesthetic thing. It just seems inelegant to be
> repeatedly destroying and recreating the socket.

That might be why Plan9 has dial(3).

The socket is the endpoint for a connection, not N connections. There
is a bunch of huzzamawhozits to get one, but that is what it's for,
elegant or no. :-/

--jkl