|
Home > Archive > Unix Programming > February 2004 > Reopen a partialy closed cosket?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Reopen a partialy closed cosket?
|
|
| Darko M. 2004-02-20, 1:34 pm |
| As we know, we can partialy close a socket by calling the shutdown
function. We can close it for reading or writing or both. If we close
it with SHUT_RDWR, it is equivalent to close(). I wonder if there is a
way to eg. close pipe for writing, and then reopen it without
reconnecting?
Thanks.
| |
| Barry Margolin 2004-02-20, 1:34 pm |
| In article <ef663480.0402201857.4c69c11e@posting.google.com>,
mdanko@tesla.rcub.bg.ac.yu (Darko M.) wrote:
> As we know, we can partialy close a socket by calling the shutdown
> function. We can close it for reading or writing or both. If we close
> it with SHUT_RDWR, it is equivalent to close(). I wonder if there is a
> way to eg. close pipe for writing, and then reopen it without
> reconnecting?
If you use SHUT_WR, a FIN is sent to the remote system, which indicates
that you will not send any more data. So reopening it for writing makes
no sense.
What are you really trying to accomplish? Why do you call shutdown() if
you don't really mean it?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Nick Landsberg 2004-02-20, 2:34 pm |
|
Darko M. wrote:
> As we know, we can partialy close a socket by calling the shutdown
> function. We can close it for reading or writing or both. If we close
> it with SHUT_RDWR, it is equivalent to close(). I wonder if there is a
> way to eg. close pipe for writing, and then reopen it without
> reconnecting?
>=20
> Thanks.
And how would you reference the now closed pipe?
Let's say you were using the system primitives and
did a opened a pipe-pair with the pipe() call,
which returns a pair of file descriptors
and then did -
close(pipe_fd[0]);
This disassaciates the process
from that file descriptor, which has no name
in the namespace available to you.
If, on the other hand, you were using named pipes, AKA fifos,
(which I believe are still around in SysV variants), you could
reopen it by using the name in the open(), call.
But that's what you would have done in the first
place anyway.
In general, closing and re-opening the same resource
is not a good idea since the open call is one of
the most expensive from a performance standpoint,
unless you are running out of open file-descriptors,
in which case I would seriously reconsider your
design.
Then again, are we talking about the same thing
when we talk about pipes? What I am talking about
is the standard Unix pipe(2) mechanism.
--=20
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch
| |
| Sean Burke 2004-02-20, 2:34 pm |
|
Nick Landsberg <hukolau@att.net> writes:
> Darko M. wrote:
>
> And how would you reference the now closed pipe?
>
> Let's say you were using the system primitives and
> did a opened a pipe-pair with the pipe() call,
> which returns a pair of file descriptors
> and then did -
>
> close(pipe_fd[0]);
>
> This disassaciates the process
> from that file descriptor, which has no name
> in the namespace available to you.
>
> If, on the other hand, you were using named pipes, AKA fifos,
> (which I believe are still around in SysV variants), you could
> reopen it by using the name in the open(), call.
> But that's what you would have done in the first
> place anyway.
>
> In general, closing and re-opening the same resource
> is not a good idea since the open call is one of
> the most expensive from a performance standpoint,
> unless you are running out of open file-descriptors,
> in which case I would seriously reconsider your
> design.
>
> Then again, are we talking about the same thing
> when we talk about pipes? What I am talking about
> is the standard Unix pipe(2) mechanism.
It appears to me that you are assuming a one-way pipe,
whereas many unii have bidirectional pipes. In that
case, you could have something analagous to shutdown(),
although I don't see any use for this myself.
-SEan
| |
| David Schwartz 2004-02-20, 4:33 pm |
|
"Darko M." <mdanko@tesla.rcub.bg.ac.yu> wrote in message
news:ef663480.0402201857.4c69c11e@posting.google.com...
> If we close
> it with SHUT_RDWR, it is equivalent to close().
No, they're not equivalent at all. For one thing, if there's another
reference to the socket, the 'close' function doesn't perform any shut down
at all. For another thing, after the 'shutdown' function, you still have a
handle to the shutdown connection.
DS
| |
| Darko M. 2004-02-21, 1:34 am |
| I understand. It really wouldn't make sense, when I think about it
more, now.
So, TCP sends FIN, you say? Interesting. And I wondered how does
shutdown() work. Now I understand.
What I actually wanted it for, is a connection to the server that must
know when the data is going to end. I didn't want any separators,
since that limits data range, nor I wanted the number of bytes come
first, since this server-conversation would consist of many very-small
data buffer exchanging, and if I put an int or two for their number,
it would spend more flow than the data itself. So I decided to read
from a server until a connection is closed. But then comes a problem
up. If the connection from the client's cide closes, then no data can
be returned as confirmation. So I come up with an idea than I've asked
you about. Shutdown the connection with server for writing (the server
will detect connection closure), and then reopen it. Maybe it's
interesting idea, but later I realised it's not too good, nor possible
(as you've said)... At the end, I found the separators-choice
reasonable, and chose it for my design.
Thanks, all of you.
| |
| Nick Landsberg 2004-02-21, 2:34 am |
|
Sean Burke wrote:
> Nick Landsberg <hukolau@att.net> writes:
>=20
>=20
[color=blue]
>=20
>=20
> It appears to me that you are assuming a one-way pipe,
> whereas many unii have bidirectional pipes. In that
> case, you could have something analagous to shutdown(),
> although I don't see any use for this myself.
>=20
> -SEan
Actually, I was considering each of the FD's returned
by pipe(2) as a separate and distinct "resource"
Closing the resource by which you access either end
of the pipe effectively disaassociates you from
that end of the pipe, and I know of no way to
re-establish that association once closed. The
pipe may still exist, there may be another process
on the other end of it but you're locked out in the
cold without a key.
I agree, I don't see any particular use for it.
>=20
>=20
--=20
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch
| |
| Barry Margolin 2004-02-21, 5:34 am |
| In article <ef663480.0402210618.44cf015e@posting.google.com>,
mdanko@tesla.rcub.bg.ac.yu (Darko M.) wrote:
> What I actually wanted it for, is a connection to the server that must
> know when the data is going to end. I didn't want any separators,
> since that limits data range, nor I wanted the number of bytes come
> first, since this server-conversation would consist of many very-small
> data buffer exchanging, and if I put an int or two for their number,
> it would spend more flow than the data itself. So I decided to read
> from a server until a connection is closed. But then comes a problem
> up. If the connection from the client's cide closes, then no data can
> be returned as confirmation.
That's not a problem. The client should use SHUT_WR, which only
half-closes it. The server will read EOF from the client, but can still
write back the response, and the client can read it.
After this, both the client and server should call close().
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| David Schwartz 2004-02-21, 5:34 am |
|
"Darko M." <mdanko@tesla.rcub.bg.ac.yu> wrote in message
news:ef663480.0402210618.44cf015e@posting.google.com...
> What I actually wanted it for, is a connection to the server that must
> know when the data is going to end. I didn't want any separators,
> since that limits data range, nor I wanted the number of bytes come
> first, since this server-conversation would consist of many very-small
> data buffer exchanging, and if I put an int or two for their number,
> it would spend more flow than the data itself. So I decided to read
> from a server until a connection is closed.
The cost of closing and re-opening a connection is much higher than the
cost of sending an extra byte or two when you're sending data anyway.
> But then comes a problem
> up. If the connection from the client's cide closes, then no data can
> be returned as confirmation. So I come up with an idea than I've asked
> you about. Shutdown the connection with server for writing (the server
> will detect connection closure), and then reopen it. Maybe it's
> interesting idea, but later I realised it's not too good, nor possible
> (as you've said)... At the end, I found the separators-choice
> reasonable, and chose it for my design.
Even if it was possible, it would have been a bad decision. Any separate
data exchange is going to be more expensive than adding an extra byte or two
to an existing data exchange. Your decision to layer a protocol that has the
features you need on top of TCP is the correct one.
DS
| |
| Alex Colvin 2004-02-21, 6:34 am |
| Oh, you meant "socket". I thought you meant "casket"!
--
mac the naïf
|
|
|
|
|