Socket problem: read & write to same socket

L

liyaohua.bupt

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();
}

}
 
A

Arne Vajhøj

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
 
L

liyaohua.bupt

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

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
 
D

Daniel Pitts

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

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

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
 
M

Martin Gregorie

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

Arne Vajhøj

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
 
M

Martin Gregorie

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

Arne Vajhøj

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
 
L

Lew

Arne said:
"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.
 
A

Arne Vajhøj

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
 
M

Martin Gregorie

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

Martin Gregorie

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

Arne Vajhøj

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
 
A

Arne Vajhøj

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
 
P

Paul Cager

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

RedGrittyBrick

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

Martin Gregorie

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

glen herrmannsfeldt

(snip)
(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
 
P

Paul Cager

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

Nigel Wade

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,787
Messages
2,569,627
Members
45,329
Latest member
InezZ76898

Latest Threads

Top