Grokbase › Groups › Go › golang-nuts › December 2012
FAQ
Hi all,

I am writing a client which connects the server through TCP and sends
some data periodically. The server may drop the connection and the
client should re-establish the connection before next Write().

This is a very typical program and I thought I could detect the closed
connection by checking the returned error from Write(). I wrote two
simple programs to see what error will be returned from Write() if the
connection is closed by the remote end. (It should be EPIPE according to
write(2))

However, the Write() operation on the closed connection returns no
error. I would like to know how can I detect the closed connection in
this case.

Here are the test programs I wrote:

- client program:
http://play.golang.org/p/cSs-AHkM2U

The logic is very simple: connect to server, wait for a second, then
write some data and print the return values from Write().

- server program:
http://play.golang.org/p/oTRtTCrKAt

Still very simple: listen on a port, if there is a connection, accept it
and close it immediately.

Regards,
-Monnand

--

Search Discussions

  • Mjarco at Dec 7, 2012 at 10:29 am ⇧
    Hi,
    This topic returns to the group from time to time. Short answer is
    to Read() from connection and if Read() returns EOF it means
    connection is closed. For more detailed explanaitions please
    browse group archives
    On Friday, December 7, 2012 7:41:36 AM UTC+1, Monnand wrote:

    Hi all,

    I am writing a client which connects the server through TCP and sends
    some data periodically. The server may drop the connection and the
    client should re-establish the connection before next Write().

    This is a very typical program and I thought I could detect the closed
    connection by checking the returned error from Write(). I wrote two
    simple programs to see what error will be returned from Write() if the
    connection is closed by the remote end. (It should be EPIPE according to
    write(2))

    However, the Write() operation on the closed connection returns no
    error. I would like to know how can I detect the closed connection in
    this case.

    Here are the test programs I wrote:

    - client program:
    http://play.golang.org/p/cSs-AHkM2U

    The logic is very simple: connect to server, wait for a second, then
    write some data and print the return values from Write().

    - server program:
    http://play.golang.org/p/oTRtTCrKAt

    Still very simple: listen on a port, if there is a connection, accept it
    and close it immediately.

    Regards,
    -Monnand
    --
  • Monnand at Dec 10, 2012 at 5:18 am ⇧

    On 12/07/2012 05:29 AM, mjarco wrote:
    Hi,
    This topic returns to the group from time to time. Short answer is
    to Read() from connection and if Read() returns EOF it means
    connection is closed. For more detailed explanaitions please
    browse group archives
    Hi Mjarco,

    Thanks for your reply!

    I did searched around the Internet and I did found some thread in this
    mailing list related to this problem. However, none of them proposed a
    solution suitable for me. Most of them, suggest to use Read() first to
    test if the connectivity of a socket.

    In my code, there are two goroutines, one for read from the socket and
    one for write to the socket. If there are some data not been processed
    by the read goroutine, the write goroutine may read the data from the
    connection when test the connectivity using Read(). It may lead to data
    corruption for the read goroutine.

    I would like to know if this (write to closed net.TCPConn without
    returning error) is a feature of net package or it should be considered
    as a bug.

    Regards,
    -Monnand

    --
  • Kyle Lemons at Dec 10, 2012 at 10:00 pm ⇧
    Your program needs to be able to handle this case. Because you are
    communicating over a network, there can always be circumstances in which
    the remote side terminates the connection before it has received some data
    that you sent. Under TCP, your operating system should be able to
    determine that this happened, but whether this is reported to you at the
    time of the Write or at the time of the Close (or not at all) will vary
    from situation to situation.

    On Mon, Dec 10, 2012 at 12:18 AM, Monnand wrote:
    On 12/07/2012 05:29 AM, mjarco wrote:

    Hi,
    This topic returns to the group from time to time. Short answer is
    to Read() from connection and if Read() returns EOF it means
    connection is closed. For more detailed explanaitions please
    browse group archives
    Hi Mjarco,

    Thanks for your reply!

    I did searched around the Internet and I did found some thread in this
    mailing list related to this problem. However, none of them proposed a
    solution suitable for me. Most of them, suggest to use Read() first to test
    if the connectivity of a socket.

    In my code, there are two goroutines, one for read from the socket and one
    for write to the socket. If there are some data not been processed by the
    read goroutine, the write goroutine may read the data from the connection
    when test the connectivity using Read(). It may lead to data corruption for
    the read goroutine.

    I would like to know if this (write to closed net.TCPConn without
    returning error) is a feature of net package or it should be considered as
    a bug.

    Regards,
    -Monnand

    --

    --
  • Kyle Lemons at Dec 10, 2012 at 10:03 pm ⇧
    Whoops, that carriage return apparently sent the email.
    On Mon, Dec 10, 2012 at 5:00 PM, Kyle Lemons wrote:

    Your program needs to be able to handle this case. Because you are
    communicating over a network, there can always be circumstances in which
    the remote side terminates the connection before it has received some data
    that you sent. Under TCP, your operating system should be able to
    determine that this happened, but whether this is reported to you at the
    time of the Write or at the time of the Close (or not at all) will vary
    from situation to situation.
    You already hava a goroutine that is handling reads, so use that to signal
    when the connection has been closed, at which point you can close the
    connection and re-establish it along with the two goroutines handling reads
    and writes.

    On Mon, Dec 10, 2012 at 12:18 AM, Monnand wrote:
    On 12/07/2012 05:29 AM, mjarco wrote:

    Hi,
    This topic returns to the group from time to time. Short answer is
    to Read() from connection and if Read() returns EOF it means
    connection is closed. For more detailed explanaitions please
    browse group archives
    Hi Mjarco,

    Thanks for your reply!

    I did searched around the Internet and I did found some thread in this
    mailing list related to this problem. However, none of them proposed a
    solution suitable for me. Most of them, suggest to use Read() first to test
    if the connectivity of a socket.

    In my code, there are two goroutines, one for read from the socket and
    one for write to the socket. If there are some data not been processed by
    the read goroutine, the write goroutine may read the data from the
    connection when test the connectivity using Read(). It may lead to data
    corruption for the read goroutine.

    I would like to know if this (write to closed net.TCPConn without
    returning error) is a feature of net package or it should be considered as
    a bug.

    Regards,
    -Monnand

    --

    --
  • Monnand at Dec 15, 2012 at 7:40 am ⇧
    Hi Kyle,

    Thanks for your reply. I have changed my code according to your advice.

    Thank you very much!

    Regards,
    -Monnand
    On Monday, December 10, 2012 5:03:28 PM UTC-5, Kyle Lemons wrote:

    Whoops, that carriage return apparently sent the email.

    On Mon, Dec 10, 2012 at 5:00 PM, Kyle Lemons <kev...@google.com<javascript:>
    wrote:
    Your program needs to be able to handle this case. Because you are
    communicating over a network, there can always be circumstances in which
    the remote side terminates the connection before it has received some data
    that you sent. Under TCP, your operating system should be able to
    determine that this happened, but whether this is reported to you at the
    time of the Write or at the time of the Close (or not at all) will vary
    from situation to situation.
    You already hava a goroutine that is handling reads, so use that to signal
    when the connection has been closed, at which point you can close the
    connection and re-establish it along with the two goroutines handling reads
    and writes.

    On Mon, Dec 10, 2012 at 12:18 AM, Monnand <mon...@gmail.com <javascript:>
    wrote:
    On 12/07/2012 05:29 AM, mjarco wrote:

    Hi,
    This topic returns to the group from time to time. Short answer is
    to Read() from connection and if Read() returns EOF it means
    connection is closed. For more detailed explanaitions please
    browse group archives
    Hi Mjarco,

    Thanks for your reply!

    I did searched around the Internet and I did found some thread in this
    mailing list related to this problem. However, none of them proposed a
    solution suitable for me. Most of them, suggest to use Read() first to test
    if the connectivity of a socket.

    In my code, there are two goroutines, one for read from the socket and
    one for write to the socket. If there are some data not been processed by
    the read goroutine, the write goroutine may read the data from the
    connection when test the connectivity using Read(). It may lead to data
    corruption for the read goroutine.

    I would like to know if this (write to closed net.TCPConn without
    returning error) is a feature of net package or it should be considered as
    a bug.

    Regards,
    -Monnand

    --

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 7, '12 at 6:41a
activeDec 15, '12 at 7:40a
posts6
users3
websitegolang.org

3 users in discussion

Monnand: 3 posts Kyle Lemons: 2 posts Mjarco: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase