Messaging Protocol

I want to send simple messages over a network using a tcp-ip client-server
model. Client makes tcp connection to server, sends some data, and waits
for an application level acknowledgement from the server that the message
has been received. Is there some standard application level protocol to
do this?

Dan

On Mon, 23 Oct 2006, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed) t>, Dan N wrote:

>I want to send simple messages over a network using a tcp-ip client-server
>model. Client makes tcp connection to server, sends some data, and waits
>for an application level acknowledgement from the server that the message
>has been received. Is there some standard application level protocol to
>do this?

[compton ~]$ whatis telnet nc
telnet (1) - user interface to the TELNET protocol
nc (1) - TCP/IP swiss army knife
[compton ~]$

Netcat (nc) for the server, telnet for the client?

Old guy

On Mon, 23 Oct 2006 15:02:41 -0500, Moe Trin wrote:


> Netcat (nc) for the server, telnet for the client?

Thanks for the suggestions. Telnet probably isn't very suitable, too much
overhead with logins etcetera. I'm thinking that maybe http is the way to
go. I'll write a short C program to send the message as an http POST.
Could even use Apache to read it.

What I need is pretty basic, send a message and get an acknowledgement
back. It would be easy enough to write this, but I was wondering if
there was already some standard protocol that I could use. No use
re-inventing the wheel.

Dan

Dan N wrote:
> On Mon, 23 Oct 2006 15:02:41 -0500, Moe Trin wrote:
>> Netcat (nc) for the server, telnet for the client?
>
> Thanks for the suggestions. Telnet probably isn't very suitable, too much
> overhead with logins etcetera.

Logins?
What logins?

> I'm thinking that maybe http is the way to
> go. I'll write a short C program to send the message as an http POST.
> Could even use Apache to read it.
>
> What I need is pretty basic, send a message and get an acknowledgement
> back. It would be easy enough to write this, but I was wondering if
> there was already some standard protocol that I could use. No use
> re-inventing the wheel.

Both telnet and netcat will allow you to do that
you probably don't have to roll your own.

On Tue, 24 Oct 2006 05:20:39 +0100, Thomas Schodt wrote:

> Both telnet and netcat will allow you to do that
> you probably don't have to roll your own.

Thanks. I'll have a closer look.

Dan

Dan N wrote:

> I want to send simple messages over a network using a tcp-ip client-server
> model. Client makes tcp connection to server, sends some data, and waits
> for an application level acknowledgement from the server that the message
> has been received. Is there some standard application level protocol to
> do this?

HTTP is probably a good choice. It is an application-level protocol
that has well defined requests and replies.

It really depends upon several things:

1) Do you need pipelining? That is, is it important to be able to issue
a request that might take a long time and be able to issue other
requests while the first one is being processed? Do you need to be able
to receive the replies out of order?

2) How large are the requests and the replies? What format are they in
and how are they structured? (Text? Binary? XML?)

3) Will a client typically be making a single reply or a series of
replies? Is it too expensive to have the overhead of establishing a TCP
connection for each request/reply pair?

4) How important is performance over simplicity or ability to
debug/trace?

5) What authentication requirements do you have?

If the 'conversation' is not a stream of logically distinct requests,
HTTP may not be a good choice. If requests change the logical state of
a connection, HTTP may not be a good choice.

If requests are like 'do this', 'do this', and 'give me this', HTTP
makes logical sense. If they're more like 'log in', 'acquire permission
to do X', and 'register for notifications if Y happens', then HTTP
makes much less sense.

DS

On Tue, 24 Oct 2006 05:15:25 -0700, David Schwartz wrote:

> HTTP is probably a good choice. It is an application-level protocol
> that has well defined requests and replies.


> Is it too expensive to have the overhead of establishing a TCP
> connection for each request/reply pair?

Thanks for the suggestions. The tcp overhead might be a problem though.
The data transfer is pretty simply, mostly client to host at regular
intervals. But the client needs an ack to know that the message got there.

Dan

On comp.os.linux.networking, in
<(E-Mail Removed)>, "Moe Trin" wrote:

> On Mon, 23 Oct 2006, in the Usenet newsgroup
> comp.os.linux.networking, in article
> <(E-Mail Removed) t>, Dan N
> wrote:
>
>>I want to send simple messages over a network using a
>>tcp-ip client-server model. Client makes tcp connection to
>>server, sends some data, and waits for an application level
>>acknowledgement from the server that the message has been
>>received. Is there some standard application level protocol to
>>do this?
>
> [compton ~]$ whatis telnet nc telnet (1) - user interface to
> the TELNET protocol nc (1) - TCP/IP swiss army knife [compton
> ~]$
>
> Netcat (nc) for the server, telnet for the client?
>

Netcat can be used for both server and client.

From the README (which is the manual):

Netcat can be used as a simple data transfer agent, and it
doesn't really matter which end is the listener and which end
is the client -- input at one side arrives at the other side as
output.

/quote

Connect to pre-arranged port on 'server' (where nc is listening)
and send 'some data' (a file) and have the 'server' send a file
(acknowledgement) back to the 'client' which would then send
whatever message (file) it had to the 'server'.

Fairly simple bash scripts. I don't know if you have ever tried
to script with telnet, but it is much simpler with nc and runs
much faster.

Alan

--
http://home.earthlink.net/~alanconnor/contact.html
http://home.earthlink.net/~alanconno...val/index.html
http://home.earthlink.net/~alanconno...nix/index.html

Thanks Beavis.

Dan N wrote:

> On Tue, 24 Oct 2006 05:15:25 -0700, David Schwartz wrote:

> > HTTP is probably a good choice. It is an application-level protocol
> > that has well defined requests and replies.

> > Is it too expensive to have the overhead of establishing a TCP
> > connection for each request/reply pair?
>
> Thanks for the suggestions. The tcp overhead might be a problem though.
> The data transfer is pretty simply, mostly client to host at regular
> intervals. But the client needs an ack to know that the message got there.

Then HTTP is probably just fine. You can use keep-alives (they are
enabled by default in HTTP/1.1) to re-use the TCP connection.

DS