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 a=
nd when I want to write to socket, it closes the connection. I used wiresha=
rk to listen to the packets. I saw my program sent a FIN to the server side=
.. So the server receives nothing.=20

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 r=
ead 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=20
	 */
	public static void main(String[] args) throws IOException {
		// TODO Auto-generated method stub
		Socket s =3D null;
		BufferedReader in =3D null;
		BufferedWriter out =3D null;
		//PrintWriter out =3D null;

		try {
			s =3D new Socket("127.0.0.1", 9999);
			in =3D new BufferedReader(new InputStreamReader(s.getInputStream()));
			//out =3D new PrintWriter(s.getOutputStream(), false);
			out =3D 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 =3D "";

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

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

}

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

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

On Tuesday, March 13, 2012 11:14:36 AM UTC-5, Arne Vajh=F8j 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 lang=
uage), read from socket, and then write into socket.
> >
> > The connection can be established, and it reads correctly. But after th=
at and when I want to write to socket, it closes the connection. I used wir=
eshark 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 bo=
th read and write.
>=20
> > 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 =3D null;
> > 		BufferedReader in =3D null;
> > 		BufferedWriter out =3D null;
> > 		//PrintWriter out =3D null;
> >
> > 		try {
> > 			s =3D new Socket("127.0.0.1", 9999);
> > 			in =3D new BufferedReader(new InputStreamReader(s.getInputStream()))=
;
> > 			//out =3D new PrintWriter(s.getOutputStream(), false);
> > 			out =3D 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 =3D "";
> >
> > 		msg =3D in.readLine();
> > 		System.out.println(msg);
> >
> > 		out.write("\"hi, socket\"");
>=20
> Try:
>=20
> out.flush();
>=20
> here.
>=20
> > 		s.close();
> > 	}
> >
> > }
>=20
> Arne

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
>

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       |

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

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       |

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=F8j wrote:
> Martin Gregorie wrote:
>> Arne Vajh=F8j 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.
>=20
> "I want to establish connection to a server(written by myself in Go
> language)"
>=20
> "Note that the server side only sends one line into socket."
>=20
> "I later wrote a server in Java and a client in Go. They work fine in
> both read and write."
>=20
> 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 rath=
er than a receive, per Martin's comment.

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

--=20
Lew

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

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       |

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       |

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

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

On Mar 13, 11:33=A0pm, 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.

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

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       |

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

On Mar 15, 12:45=A0am, 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).

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