Professional Web Applications Themes

Reopen a partialy closed cosket? - UNIX Programming

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....

Sponsored Links
  1. #1

    Default Reopen a partialy closed cosket?

    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.
    Sponsored Links
    Darko Guest

  2. #2

    Default Re: Reopen a partialy closed cosket?

    In article <google.com>,
    rcub.bg.ac.yu (Darko M.) wrote:
     

    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, mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Guest

  3. #3

    Default Re: Reopen a partialy closed cosket?



    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 is impossible to make anything foolproof because fools are so
    ingenious" - A. Bloch

    Nick Guest

  4. #4

    Default Re: Reopen a partialy closed cosket?


    Nick Landsberg <net> writes:
     
    >
    > 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.[/ref]

    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 agous to shutdown(),
    although I don't see any use for this myself.

    -SEan




    Sean Guest

  5. #5

    Default Re: Reopen a partialy closed cosket?


    "Darko M." <rcub.bg.ac.yu> wrote in message
    news:google.com... 

    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



    David Guest

  6. #6

    Default Re: Reopen a partialy closed cosket?

    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.
    Darko Guest

  7. #7

    Default Re: Reopen a partialy closed cosket?



    Sean Burke 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.[/ref]
    >
    >
    > 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 agous to shutdown(),
    > although I don't see any use for this myself.
    >
    > -SEan[/ref]

    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.
     

    --

    "It is impossible to make anything foolproof because fools are so
    ingenious" - A. Bloch

    Nick Guest

  8. #8

    Default Re: Reopen a partialy closed cosket?


    "Darko M." <rcub.bg.ac.yu> wrote in message
    news:google.com...

     

    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.
     


    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



    David Guest

  9. #9

    Default Re: Reopen a partialy closed cosket?

    In article <google.com>,
    rcub.bg.ac.yu (Darko M.) wrote:
     

    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, mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Guest

  10. #10

    Default Re: Reopen a partialy closed cosket?

    Oh, you meant "socket". I thought you meant "casket"!

    --
    mac the naf
    Alex Guest

Similar Threads

  1. Close PDF file and reopen it
    By NoSmoking@adobeforums.com in forum Adobe Acrobat SDK
    Replies: 6
    Last Post: December 12th, 11:26 AM
  2. Unable to reopen EPS from CS in PS7
    By Chris_Cox@adobeforums.com in forum Adobe Photoshop Mac CS, CS2 & CS3
    Replies: 0
    Last Post: April 1st, 12:48 AM
  3. HELP! Closing POP UP doesn't let me reopen it!
    By Hobak in forum Macromedia Flash
    Replies: 0
    Last Post: October 28th, 11:20 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139