Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #12960 > unrolled thread

Socket problem: read & write to same socket

Back to article view | Back to comp.lang.java.programmer

Contents

  Socket problem: read & write to same socket liyaohua.bupt@gmail.com - 2012-03-13 09:01 -0700
    Re: Socket problem: read & write to same socket Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 12:14 -0400
      Re: Socket problem: read & write to same socket liyaohua.bupt@gmail.com - 2012-03-13 09:30 -0700
        Re: Socket problem: read & write to same socket Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-13 10:30 -0700
    Re: Socket problem: read & write to same socket Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-13 21:33 +0000
      Re: Socket problem: read & write to same socket Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 17:48 -0400
        Re: Socket problem: read & write to same socket Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-13 22:03 +0000
          Re: Socket problem: read & write to same socket Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 18:25 -0400
            Re: Socket problem: read & write to same socket Lew <lewbloch@gmail.com> - 2012-03-13 15:38 -0700
              Re: Socket problem: read & write to same socket Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 18:47 -0400
                Re: Socket problem: read & write to same socket Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-13 23:33 +0000
                  Re: Socket problem: read & write to same socket Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 19:35 -0400
                  Re: Socket problem: read & write to same socket Paul Cager <paul.cager@googlemail.com> - 2012-03-14 02:51 -0700
                    Re: Socket problem: read & write to same socket Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-15 00:45 +0000
                      Re: Socket problem: read & write to same socket Paul Cager <paul.cager@googlemail.com> - 2012-03-15 03:18 -0700
                  Re: Socket problem: read & write to same socket RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2012-03-14 16:22 +0000
                    Re: Socket problem: read & write to same socket glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-15 01:33 +0000
                  Re: Socket problem: read & write to same socket Nigel Wade <nmw@le.ac.uk> - 2012-03-15 12:30 +0000
            Re: Socket problem: read & write to same socket Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-13 23:00 +0000
              Re: Socket problem: read & write to same socket Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 19:36 -0400

#12960 — Socket problem: read & write to same socket

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

}

[toc] | [next] | [standalone]

#12961

On 3/13/2012 12:01 PM, liyaohua.bupt@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#12966

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, liyaohua.bupt@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#12975

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, liyaohua.bupt@gmail.com 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, liyaohua.bupt@gmail.com 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
>

[toc] | [prev] | [next] | [standalone]

#12986

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       |

[toc] | [prev] | [next] | [standalone]

#12987

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

[toc] | [prev] | [next] | [standalone]

#12989

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       |

[toc] | [prev] | [next] | [standalone]

#12990

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

[toc] | [prev] | [next] | [standalone]

#12991

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

[toc] | [prev] | [next] | [standalone]

#12992

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

[toc] | [prev] | [next] | [standalone]

#12994

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       |

[toc] | [prev] | [next] | [standalone]

#12995

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

[toc] | [prev] | [next] | [standalone]

#13001

On Mar 13, 11:33 pm, Martin Gregorie <mar...@address-in-sig.invalid>
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.

[toc] | [prev] | [next] | [standalone]

#13011

On Wed, 14 Mar 2012 02:51:29 -0700, Paul Cager wrote:

> On Mar 13, 11:33 pm, Martin Gregorie <mar...@address-in-sig.invalid>
> 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       |

[toc] | [prev] | [next] | [standalone]

#13015

On Mar 15, 12:45 am, Martin Gregorie <mar...@address-in-sig.invalid>
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).

[toc] | [prev] | [next] | [standalone]

#13005

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

[toc] | [prev] | [next] | [standalone]

#13014

RedGrittyBrick <RedGrittyBrick@spamweary.invalid> 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

[toc] | [prev] | [next] | [standalone]

#13019

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

[toc] | [prev] | [next] | [standalone]

#12993

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       |

[toc] | [prev] | [next] | [standalone]

#12996

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web