Socket problem: read & write to same socket

Discussion in 'Java' started by liyaohua.bupt@gmail.com, Mar 13, 2012.

  1. Guest

    I want to establish connection to a server(written by myself in Go language), read from socket, and then write into socket.

    The connection can be established, and it reads correctly. But after that and when I want to write to socket, it closes the connection. I used wireshark to listen to the packets. I saw my program sent a FIN to the server side.. So the server receives nothing.

    Note that the server side only sends one line into socket.

    I later wrote a server in Java and a client in Go. They work fine in both read and write.

    Thanks in advance!



    import java.io.BufferedReader;
    import java.io.BufferedWriter;
    import java.io.IOException;
    import java.io.InputStreamReader;
    import java.io_OutputStreamWriter;
    import java.io.PrintWriter;
    import java.net.Socket;
    import java.net.UnknownHostException;



    public class DeserializerTester {

    /**
    * @param args
    * @throws IOException
    */
    public static void main(String[] args) throws IOException {
    // TODO Auto-generated method stub
    Socket s = null;
    BufferedReader in = null;
    BufferedWriter out = null;
    //PrintWriter out = null;

    try {
    s = new Socket("127.0.0.1", 9999);
    in = new BufferedReader(new InputStreamReader(s.getInputStream()));
    //out = new PrintWriter(s.getOutputStream(), false);
    out = new BufferedWriter(new OutputStreamWriter(s.getOutputStream()));
    } catch (UnknownHostException e) {
    System.err.println("Unknown host");
    System.exit(0);
    } catch (IOException e) {
    System.err.println("IO error");
    System.exit(1);
    }

    String msg = "";

    msg = in.readLine();
    System.out.println(msg);

    out.write("\"hi, socket\"");
    s.close();
    }

    }
     
    , Mar 13, 2012
    #1
    1. Advertising

  2. Arne Vajhøj Guest

    On 3/13/2012 12:01 PM, wrote:
    > I want to establish connection to a server(written by myself in Go language), read from socket, and then write into socket.
    >
    > The connection can be established, and it reads correctly. But after that and when I want to write to socket, it closes the connection. I used wireshark to listen to the packets. I saw my program sent a FIN to the server side. So the server receives nothing.
    >
    > Note that the server side only sends one line into socket.
    >
    > I later wrote a server in Java and a client in Go. They work fine in both read and write.


    > import java.io.BufferedReader;
    > import java.io.BufferedWriter;
    > import java.io.IOException;
    > import java.io.InputStreamReader;
    > import java.io_OutputStreamWriter;
    > import java.io.PrintWriter;
    > import java.net.Socket;
    > import java.net.UnknownHostException;
    >
    > public class DeserializerTester {
    > public static void main(String[] args) throws IOException {
    > // TODO Auto-generated method stub
    > Socket s = null;
    > BufferedReader in = null;
    > BufferedWriter out = null;
    > //PrintWriter out = null;
    >
    > try {
    > s = new Socket("127.0.0.1", 9999);
    > in = new BufferedReader(new InputStreamReader(s.getInputStream()));
    > //out = new PrintWriter(s.getOutputStream(), false);
    > out = new BufferedWriter(new OutputStreamWriter(s.getOutputStream()));
    > } catch (UnknownHostException e) {
    > System.err.println("Unknown host");
    > System.exit(0);
    > } catch (IOException e) {
    > System.err.println("IO error");
    > System.exit(1);
    > }
    >
    > String msg = "";
    >
    > msg = in.readLine();
    > System.out.println(msg);
    >
    > out.write("\"hi, socket\"");


    Try:

    out.flush();

    here.

    > s.close();
    > }
    >
    > }


    Arne
     
    Arne Vajhøj, Mar 13, 2012
    #2
    1. Advertising

  3. Guest

    It works! Thanks! It busted me for quite a while.

    On Tuesday, March 13, 2012 11:14:36 AM UTC-5, Arne Vajhøj wrote:
    > On 3/13/2012 12:01 PM, wrote:
    > > I want to establish connection to a server(written by myself in Go language), read from socket, and then write into socket.
    > >
    > > The connection can be established, and it reads correctly. But after that and when I want to write to socket, it closes the connection. I used wireshark to listen to the packets. I saw my program sent a FIN to the server side. So the server receives nothing.
    > >
    > > Note that the server side only sends one line into socket.
    > >
    > > I later wrote a server in Java and a client in Go. They work fine in both read and write.

    >
    > > import java.io.BufferedReader;
    > > import java.io.BufferedWriter;
    > > import java.io.IOException;
    > > import java.io.InputStreamReader;
    > > import java.io_OutputStreamWriter;
    > > import java.io.PrintWriter;
    > > import java.net.Socket;
    > > import java.net.UnknownHostException;
    > >
    > > public class DeserializerTester {
    > > public static void main(String[] args) throws IOException {
    > > // TODO Auto-generated method stub
    > > Socket s = null;
    > > BufferedReader in = null;
    > > BufferedWriter out = null;
    > > //PrintWriter out = null;
    > >
    > > try {
    > > s = new Socket("127.0.0.1", 9999);
    > > in = new BufferedReader(new InputStreamReader(s.getInputStream()));
    > > //out = new PrintWriter(s.getOutputStream(), false);
    > > out = new BufferedWriter(new OutputStreamWriter(s.getOutputStream()));
    > > } catch (UnknownHostException e) {
    > > System.err.println("Unknown host");
    > > System.exit(0);
    > > } catch (IOException e) {
    > > System.err.println("IO error");
    > > System.exit(1);
    > > }
    > >
    > > String msg = "";
    > >
    > > msg = in.readLine();
    > > System.out.println(msg);
    > >
    > > out.write("\"hi, socket\"");

    >
    > Try:
    >
    > out.flush();
    >
    > here.
    >
    > > s.close();
    > > }
    > >
    > > }

    >
    > Arne
     
    , Mar 13, 2012
    #3
  4. Daniel Pitts Guest

    Liyaohua, please realize the reason is that you use a BufferedWriter,
    and you close the socket directly. The BufferedWriter has no way to
    hook into that close and flush itself. out.close instead of s.close()
    would achieve the same thing. Beware though that sometimes you don't
    want to close a socket just because you're done with the OutputStream
    (or InputStream).

    Sorry to top post but I'm afraid the OP might not see this comment
    otherwise...

    On 3/13/12 9:30 AM, wrote:
    > It works! Thanks! It busted me for quite a while.
    >
    > On Tuesday, March 13, 2012 11:14:36 AM UTC-5, Arne Vajhøj wrote:
    >> On 3/13/2012 12:01 PM, wrote:
    >>> I want to establish connection to a server(written by myself in Go language), read from socket, and then write into socket.
    >>>
    >>> The connection can be established, and it reads correctly. But after that and when I want to write to socket, it closes the connection. I used wireshark to listen to the packets. I saw my program sent a FIN to the server side. So the server receives nothing.
    >>>
    >>> Note that the server side only sends one line into socket.
    >>>
    >>> I later wrote a server in Java and a client in Go. They work fine in both read and write.

    >>
    >>> import java.io.BufferedReader;
    >>> import java.io.BufferedWriter;
    >>> import java.io.IOException;
    >>> import java.io.InputStreamReader;
    >>> import java.io_OutputStreamWriter;
    >>> import java.io.PrintWriter;
    >>> import java.net.Socket;
    >>> import java.net.UnknownHostException;
    >>>
    >>> public class DeserializerTester {
    >>> public static void main(String[] args) throws IOException {
    >>> // TODO Auto-generated method stub
    >>> Socket s = null;
    >>> BufferedReader in = null;
    >>> BufferedWriter out = null;
    >>> //PrintWriter out = null;
    >>>
    >>> try {
    >>> s = new Socket("127.0.0.1", 9999);
    >>> in = new BufferedReader(new InputStreamReader(s.getInputStream()));
    >>> //out = new PrintWriter(s.getOutputStream(), false);
    >>> out = new BufferedWriter(new OutputStreamWriter(s.getOutputStream()));
    >>> } catch (UnknownHostException e) {
    >>> System.err.println("Unknown host");
    >>> System.exit(0);
    >>> } catch (IOException e) {
    >>> System.err.println("IO error");
    >>> System.exit(1);
    >>> }
    >>>
    >>> String msg = "";
    >>>
    >>> msg = in.readLine();
    >>> System.out.println(msg);
    >>>
    >>> out.write("\"hi, socket\"");

    >>
    >> Try:
    >>
    >> out.flush();
    >>
    >> here.
    >>
    >>> s.close();
    >>> }
    >>>
    >>> }

    >>
    >> Arne

    >
     
    Daniel Pitts, Mar 13, 2012
    #4
  5. On Tue, 13 Mar 2012 09:01:44 -0700, liyaohua.bupt wrote:

    > I want to establish connection to a server(written by myself in Go
    > language), read from socket, and then write into socket.
    >
    > The connection can be established, and it reads correctly. But after
    > that and when I want to write to socket, it closes the connection. I
    > used wireshark to listen to the packets. I saw my program sent a FIN to
    > the server side. So the server receives nothing.
    >
    > Note that the server side only sends one line into socket.
    >
    > I later wrote a server in Java and a client in Go. They work fine in
    > both read and write.
    >

    Your code may accept one connection, read from and write to it, and close
    it, but its not a server because:

    (a) it doesn't listen for connections

    (b) it hasn't the right logical structure for accepting more than
    one connection either serially or in parallel with an existing
    connection

    (c) it stops itself without receiving a 'stop' command

    If your GO server uses similar logic, frankly I'm not surprised it isn't
    doing anything useful. The logic you've written might function as a
    service under the Unix superserver xinetd, but in that case it would not
    be using a Socket: it would be using System.in and System.out to handle
    messages passed to it via xinetd.

    Anything claims to be a freestanding Java server should be listening for
    connections on a ServerSocket instead of a Socket and, whenever it
    accepts an incoming connection it should do this:

    on connect:
    if connection limit reached
    send a connection rejected message
    else
    spawn a worker thread and pass it the connection
    while connected
    accept input
    validate input
    do work
    send response

    close the socket
    terminate the thread

    The server should keep on listening for and acception connections until
    it is stopped by a command: it should never terminate itself until it
    receives a positive request to do so.

    There are a variety of ways of telling a server to stop, including clock
    watching or monitoring a database, but I normally use a special control
    client that can stop the server, query its status, etc. because this
    reuses the same mechanism as its other clients and so is easy to
    implement.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Mar 13, 2012
    #5
  6. On 3/13/2012 5:33 PM, Martin Gregorie wrote:
    > On Tue, 13 Mar 2012 09:01:44 -0700, liyaohua.bupt wrote:
    >
    >> I want to establish connection to a server(written by myself in Go
    >> language), read from socket, and then write into socket.
    >>
    >> The connection can be established, and it reads correctly. But after
    >> that and when I want to write to socket, it closes the connection. I
    >> used wireshark to listen to the packets. I saw my program sent a FIN to
    >> the server side. So the server receives nothing.
    >>
    >> Note that the server side only sends one line into socket.
    >>
    >> I later wrote a server in Java and a client in Go. They work fine in
    >> both read and write.
    >>

    > Your code may accept one connection, read from and write to it, and close
    > it, but its not a server because:
    >
    > (a) it doesn't listen for connections
    >
    > (b) it hasn't the right logical structure for accepting more than
    > one connection either serially or in parallel with an existing
    > connection
    >
    > (c) it stops itself without receiving a 'stop' command
    >
    > If your GO server uses similar logic, frankly I'm not surprised it isn't
    > doing anything useful.


    I believe the code shown was for a client.

    Arne
     
    Arne Vajhøj, Mar 13, 2012
    #6
  7. On Tue, 13 Mar 2012 17:48:18 -0400, Arne Vajhøj wrote:

    > On 3/13/2012 5:33 PM, Martin Gregorie wrote:
    >> On Tue, 13 Mar 2012 09:01:44 -0700, liyaohua.bupt wrote:
    >>
    >>> I want to establish connection to a server(written by myself in Go
    >>> language), read from socket, and then write into socket.
    >>>
    >>> The connection can be established, and it reads correctly. But after
    >>> that and when I want to write to socket, it closes the connection. I
    >>> used wireshark to listen to the packets. I saw my program sent a FIN
    >>> to the server side. So the server receives nothing.
    >>>
    >>> Note that the server side only sends one line into socket.
    >>>
    >>> I later wrote a server in Java and a client in Go. They work fine in
    >>> both read and write.
    >>>

    >> Your code may accept one connection, read from and write to it, and
    >> close it, but its not a server because:
    >>
    >> (a) it doesn't listen for connections
    >>
    >> (b) it hasn't the right logical structure for accepting more than
    >> one connection either serially or in parallel with an existing
    >> connection
    >>
    >> (c) it stops itself without receiving a 'stop' command
    >>
    >> If your GO server uses similar logic, frankly I'm not surprised it
    >> isn't doing anything useful.

    >
    > I believe the code shown was for a client.
    >

    I don't think so for two reasons:

    Firstly, to quote the last line before the Java source "I later wrote a
    server in Java and a client in Go. They work fine in both read and write."

    Secondly, because it reads before it writes - something I've never seen a
    client do, though ymmv.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Mar 13, 2012
    #7
  8. On 3/13/2012 6:03 PM, Martin Gregorie wrote:
    > On Tue, 13 Mar 2012 17:48:18 -0400, Arne Vajhøj wrote:
    >
    >> On 3/13/2012 5:33 PM, Martin Gregorie wrote:
    >>> On Tue, 13 Mar 2012 09:01:44 -0700, liyaohua.bupt wrote:
    >>>
    >>>> I want to establish connection to a server(written by myself in Go
    >>>> language), read from socket, and then write into socket.
    >>>>
    >>>> The connection can be established, and it reads correctly. But after
    >>>> that and when I want to write to socket, it closes the connection. I
    >>>> used wireshark to listen to the packets. I saw my program sent a FIN
    >>>> to the server side. So the server receives nothing.
    >>>>
    >>>> Note that the server side only sends one line into socket.
    >>>>
    >>>> I later wrote a server in Java and a client in Go. They work fine in
    >>>> both read and write.
    >>>>
    >>> Your code may accept one connection, read from and write to it, and
    >>> close it, but its not a server because:
    >>>
    >>> (a) it doesn't listen for connections
    >>>
    >>> (b) it hasn't the right logical structure for accepting more than
    >>> one connection either serially or in parallel with an existing
    >>> connection
    >>>
    >>> (c) it stops itself without receiving a 'stop' command
    >>>
    >>> If your GO server uses similar logic, frankly I'm not surprised it
    >>> isn't doing anything useful.

    >>
    >> I believe the code shown was for a client.
    >>

    > I don't think so for two reasons:
    >
    > Firstly, to quote the last line before the Java source "I later wrote a
    > server in Java and a client in Go. They work fine in both read and write."
    >
    > Secondly, because it reads before it writes - something I've never seen a
    > client do, though ymmv.


    "I want to establish connection to a server(written by myself in Go
    language)"

    "Note that the server side only sends one line into socket."

    "I later wrote a server in Java and a client in Go. They work fine in
    both read and write."

    I can not read that as anything else than Java client go server.

    Arne
     
    Arne Vajhøj, Mar 13, 2012
    #8
  9. Lew Guest

    Arne Vajhøj wrote:
    > Martin Gregorie wrote:
    >> Arne Vajhøj wrote:
    >>> I believe the code shown was for a client.
    >>>

    >> I don't think so for two reasons:
    >>
    >> Firstly, to quote the last line before the Java source "I later wrote a
    >> server in Java and a client in Go. They work fine in both read and write.."
    >>
    >> Secondly, because it reads before it writes - something I've never seen a
    >> client do, though ymmv.

    >
    > "I want to establish connection to a server(written by myself in Go
    > language)"
    >
    > "Note that the server side only sends one line into socket."
    >
    > "I later wrote a server in Java and a client in Go. They work fine in
    > both read and write."
    >
    > I can not read that as anything else than Java client go server.


    Then the OP may want to have the first thing the client does be a send rather than a receive, per Martin's comment.

    Since we haven't seen the server code it's pretty hard to diagnose the problem. If the OP gives us the other half of the story then we can help more.

    --
    Lew
     
    Lew, Mar 13, 2012
    #9
  10. Arne Vajhøj Guest

    On 3/13/2012 6:38 PM, Lew wrote:
    > Arne Vajhøj wrote:
    >> Martin Gregorie wrote:
    >>> Arne Vajhøj wrote:
    >>>> I believe the code shown was for a client.
    >>>>
    >>> I don't think so for two reasons:
    >>>
    >>> Firstly, to quote the last line before the Java source "I later wrote a
    >>> server in Java and a client in Go. They work fine in both read and write."
    >>>
    >>> Secondly, because it reads before it writes - something I've never seen a
    >>> client do, though ymmv.

    >>
    >> "I want to establish connection to a server(written by myself in Go
    >> language)"
    >>
    >> "Note that the server side only sends one line into socket."
    >>
    >> "I later wrote a server in Java and a client in Go. They work fine in
    >> both read and write."
    >>
    >> I can not read that as anything else than Java client go server.

    >
    > Then the OP may want to have the first thing the client does be a send rather than a receive, per Martin's comment.


    Why?

    It is way more common for client to send first, but there is no
    reason why server sending first should not work.

    >
    > Since we haven't seen the server code it's pretty hard to diagnose the problem. If the OP gives us the other half of the story then we can help more.


    According to the last post from OP his problem is solved now.

    Arne
     
    Arne Vajhøj, Mar 13, 2012
    #10
  11. On Tue, 13 Mar 2012 18:25:03 -0400, Arne Vajhøj wrote:

    > "I want to establish connection to a server(written by myself in Go
    > language)"
    >
    > "Note that the server side only sends one line into socket."
    >
    > "I later wrote a server in Java and a client in Go. They work fine in
    > both read and write."
    >
    > I can not read that as anything else than Java client go server.
    >

    I don't see that: first he says both in GO, which didn't work. Then he
    says server in Java and client in GO. I really don't see how you read
    "Java client" into that though, with the added flush() it does work like
    a client to "netcat -l -p 9999" - provided you expect a client to read
    before it writes, which I certainly don't.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Mar 13, 2012
    #11
  12. On Tue, 13 Mar 2012 18:47:36 -0400, Arne Vajhøj wrote:

    > On 3/13/2012 6:38 PM, Lew wrote:
    >> Then the OP may want to have the first thing the client does be a send
    >> rather than a receive, per Martin's comment.

    >
    > Why?
    >
    > It is way more common for client to send first, but there is no reason
    > why server sending first should not work.
    >

    I've been thinking over the servers protocols I know. The only one I can
    think of where the process accepting the connection speaks first is SMTP,
    where the server that accepts the connection announces who it is before
    seeing what its peer has to say. Arguably, this is a slightly different
    case since SMTP is a peer-to-peer protocol rather than a client-server
    one.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Mar 13, 2012
    #12
  13. On 3/13/2012 7:33 PM, Martin Gregorie wrote:
    > On Tue, 13 Mar 2012 18:47:36 -0400, Arne Vajhøj wrote:
    >> On 3/13/2012 6:38 PM, Lew wrote:
    >>> Then the OP may want to have the first thing the client does be a send
    >>> rather than a receive, per Martin's comment.

    >>
    >> Why?
    >>
    >> It is way more common for client to send first, but there is no reason
    >> why server sending first should not work.
    >>

    > I've been thinking over the servers protocols I know. The only one I can
    > think of where the process accepting the connection speaks first is SMTP,
    > where the server that accepts the connection announces who it is before
    > seeing what its peer has to say. Arguably, this is a slightly different
    > case since SMTP is a peer-to-peer protocol rather than a client-server
    > one.


    For protocols where server send first, then I sometimes like
    to use the terms:
    TCP level server & app level client
    TCP level client & app level server

    Arne
     
    Arne Vajhøj, Mar 13, 2012
    #13
  14. On 3/13/2012 7:00 PM, Martin Gregorie wrote:
    > On Tue, 13 Mar 2012 18:25:03 -0400, Arne Vajhøj wrote:
    >
    >> "I want to establish connection to a server(written by myself in Go
    >> language)"
    >>
    >> "Note that the server side only sends one line into socket."
    >>
    >> "I later wrote a server in Java and a client in Go. They work fine in
    >> both read and write."
    >>
    >> I can not read that as anything else than Java client go server.
    >>

    > I don't see that: first he says both in GO, which didn't work. Then he
    > says server in Java and client in GO. I really don't see how you read
    > "Java client" into that though, with the added flush() it does work like
    > a client to "netcat -l -p 9999" - provided you expect a client to read
    > before it writes, which I certainly don't.


    He does not write anything about both being go. He write that the
    server is in go. And then post Java code which (at least at the
    TCP level) is client.

    Arne
     
    Arne Vajhøj, Mar 13, 2012
    #14
  15. Paul Cager Guest

    On Mar 13, 11:33 pm, Martin Gregorie <>
    wrote:
    > I've been thinking over the servers protocols I know. The only one I can
    > think of where the process accepting the connection speaks first is SMTP,
    > where the server that accepts the connection announces who it is before
    > seeing what its peer has to say. Arguably, this is a slightly different
    > case since SMTP is a peer-to-peer protocol rather than a client-server
    > one.


    There's also SSH and (if I remember correctly) the "time" protocol.
     
    Paul Cager, Mar 14, 2012
    #15
  16. On 13/03/2012 23:33, Martin Gregorie wrote:
    > On Tue, 13 Mar 2012 18:47:36 -0400, Arne Vajhøj wrote:
    >
    >> On 3/13/2012 6:38 PM, Lew wrote:
    >>> Then the OP may want to have the first thing the client does be a send
    >>> rather than a receive, per Martin's comment.

    >>
    >> Why?
    >>
    >> It is way more common for client to send first, but there is no reason
    >> why server sending first should not work.
    >>

    > I've been thinking over the servers protocols I know. The only one I can
    > think of where the process accepting the connection speaks first is SMTP,
    > where the server that accepts the connection announces who it is before
    > seeing what its peer has to say. Arguably, this is a slightly different
    > case since SMTP is a peer-to-peer protocol rather than a client-server
    > one.
    >
    >


    I suspect there are several simple protocols where the server speaks
    first (or only).

    RFC867

    TCP Based Daytime Service

    One daytime service is defined as a connection based application on
    TCP. A server listens for TCP connections on TCP port 13. Once a
    connection is established the current date and time is sent out the
    connection as a ascii character string (and any data received is
    thrown away). The service closes the connection after sending the
    quote.

    --
    RGB
     
    RedGrittyBrick, Mar 14, 2012
    #16
  17. On Wed, 14 Mar 2012 02:51:29 -0700, Paul Cager wrote:

    > On Mar 13, 11:33 pm, Martin Gregorie <>
    > wrote:
    >> I've been thinking over the servers protocols I know. The only one I
    >> can think of where the process accepting the connection speaks first is
    >> SMTP,
    >> where the server that accepts the connection announces who it is before
    >> seeing what its peer has to say. Arguably, this is a slightly different
    >> case since SMTP is a peer-to-peer protocol rather than a client-server
    >> one.

    >
    > There's also SSH and (if I remember correctly) the "time" protocol.
    >

    I wasn't certain about SSH since I haven't read the RFC and thought the
    initial prompts for password and on initial connection to a host could
    have been output by the client.

    Is NTP client server or peer to peer? I assume the latter since a copy of
    the NTP daemon function more or less as a client if its only local time
    source is the system clock.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Mar 15, 2012
    #17
  18. RedGrittyBrick <> wrote:

    (snip)
    >> I've been thinking over the servers protocols I know. The only one I can
    >> think of where the process accepting the connection speaks first is SMTP,
    >> where the server that accepts the connection announces who it is before
    >> seeing what its peer has to say. Arguably, this is a slightly different
    >> case since SMTP is a peer-to-peer protocol rather than a client-server
    >> one.


    (snip)
    > TCP Based Daytime Service


    > One daytime service is defined as a connection based application on
    > TCP. A server listens for TCP connections on TCP port 13. Once a
    > connection is established the current date and time is sent out the
    > connection as a ascii character string (and any data received is
    > thrown away). The service closes the connection after sending the
    > quote.


    A TCP connection is bidirectional, with two separate data streams.
    TCP doesn't care which goes first. TCP uses a three-way handshake
    to open the connection, normally with no data in those packets,
    but I believe there can be.

    For UDP, the client has to go first, though there doesn't need
    to be any data in the request. A packet with data length zero can
    still be considered a request to the server. In some cases, a zero
    length reply could be considered an answer from the server.

    -- glen
     
    glen herrmannsfeldt, Mar 15, 2012
    #18
  19. Paul Cager Guest

    On Mar 15, 12:45 am, Martin Gregorie <>
    wrote:

    > I wasn't certain about SSH since I haven't read the RFC and thought the
    > initial prompts for password and on initial connection to a host could
    > have been output by the client.
    >
    > Is NTP client server or peer to peer? I assume the latter since a copy of
    > the NTP daemon function more or less as a client if its only local time
    > source is the system clock.


    I'm not sure about NTP. The one I was thinking of was
    http://en.wikipedia.org/wiki/Time_Protocol (and that's only in my mind
    because the netty project uses it as an example).
     
    Paul Cager, Mar 15, 2012
    #19
  20. Nigel Wade Guest

    On 13/03/12 23:33, Martin Gregorie wrote:
    > On Tue, 13 Mar 2012 18:47:36 -0400, Arne Vajhøj wrote:
    >
    >> On 3/13/2012 6:38 PM, Lew wrote:
    >>> Then the OP may want to have the first thing the client does be a send
    >>> rather than a receive, per Martin's comment.

    >>
    >> Why?
    >>
    >> It is way more common for client to send first, but there is no reason
    >> why server sending first should not work.
    >>

    > I've been thinking over the servers protocols I know. The only one I can
    > think of where the process accepting the connection speaks first is SMTP,
    > where the server that accepts the connection announces who it is before
    > seeing what its peer has to say. Arguably, this is a slightly different
    > case since SMTP is a peer-to-peer protocol rather than a client-server
    > one.
    >
    >


    SMTP is most definitely a client-server protocol.

    There are strict clients (MCA, mail client agents), which only ever submit messages to a server.
    There are strict servers (MDA, mail delivery agents), which only ever receive messages for local delivery.
    Then there are servers (MTA, mail transport agents) which act as servers to receive messages, and as clients to forward messages to other servers.

    Just because a MTA can act as both client and server doesn't change the fact that the protocol it uses is client-server. A new connection is established for every transaction, the MTA will be a server in that connection when receiving messages and a client when forwarding them.

    --
    Nigel Wade
     
    Nigel Wade, Mar 15, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. gabor
    Replies:
    19
    Views:
    1,147
    Steve Holden
    May 31, 2005
  2. Jp Calderone
    Replies:
    7
    Views:
    1,217
    Mike Meyer
    May 28, 2005
  3. Jp Calderone
    Replies:
    0
    Views:
    466
    Jp Calderone
    May 27, 2005
  4. Leo Jay
    Replies:
    0
    Views:
    343
    Leo Jay
    Aug 22, 2008
  5. Jean-Paul Calderone
    Replies:
    0
    Views:
    1,140
    Jean-Paul Calderone
    Aug 22, 2008
Loading...

Share This Page