Question on Client - Server communication

Question on Client - Server communication

[Preben Randhol]

I'm doing a small program to learn a bit about socket programming with
clients and servers. Besides I need the program.

What I want is an application that can talk to the same application
running on a different machine. This is ok and no problem. However I
cannot know the port the application is listening to (there may be
several users runnig the same application on the same machine).
Therefore in order to contact the other application I need a server
running on each machine with a known port number. Then I can do this (_A
= on machine A, _B on machine B): App_A contacts Server_B which tells
App_B to contact App_A on port XXXX. So Server_B will only deliver this
message to App_B and not the whole stream between the two. Does this
seem like a OK way to do this? Or is there a better way using socket
programming (not GLADE). 

Now there is two ways of doing this as I see it. 

   Should App_B and Server_B keep an open connection at all time so that
   Server_B can tell App_B to contact App_A? 

   If Server_B or App_B is closed at some point then App_B can try to
   connect again as it can see that the socket when down.

   Or

   Should App_B contact Server_B on startup and say hi I am user ZZZZ
   you can contact me on port YYYY and then close the connection so that
   Server_B only contact port YYYY when needed?

   The latter can be a bit problematic if App_B is closed and opened
   again. Another problem is if the Server_B is closed and opened again
   as it then looses all the port numbers and username.

App_A and App_B must be run at all time so that the user can either
recieve or send requests. 

Thanks for any hints in advance.

(I'm using GNAT 3.14p with AdaSockets)
-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: Question on Client - Server communication

[John R. Strohm]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

This is an OLD, OLD problem, dating back to the very first days of the
ARPAnet, *LONG* before Al Gore invented the Internet, LONG before ANYONE
invented the Internet, long before there WAS an Internet.

The original ARPAnet protocol designers recognized later that they blew it
by not designing a general reconnect protocol that everyone could use.

As I recall from reading the BBN Internet Protocol Handbook in the late
1970s/early 1980s, the method they adopted way back in the Dark Ages was
this:  the server listened on a well-known port.  Clients connected on that
port.  The server chose a random port to service that client, told the
client to reconnect on that port, closed the existing connection, then
reopened the port and listened again.  The client closed his end, and
reconnected to the new port, did his thing, and closed the connection.

The idea was that a particular server could be serving multiple clients on
the same client computer, and so each client had to have a unique connection
(pair of ports).  (Remember, this was in the age of timesharing.)

I think the early versions of File Transfer Protocol did this.  I don't know
what the current versions do, and it is too early in the morning to dig
through 70-odd pages of RFC 959.

"Preben Randhol" <randhol+ada@pvv.org> wrote in message
news:mailman.1025856482.6739.comp.lang.ada@ada.eu.org...
> I'm doing a small program to learn a bit about socket programming with
> clients and servers. Besides I need the program.
>
> What I want is an application that can talk to the same application
> running on a different machine. This is ok and no problem. However I
> cannot know the port the application is listening to (there may be
> several users runnig the same application on the same machine).
> Therefore in order to contact the other application I need a server
> running on each machine with a known port number. Then I can do this (_A
> = on machine A, _B on machine B): App_A contacts Server_B which tells
> App_B to contact App_A on port XXXX. So Server_B will only deliver this
> message to App_B and not the whole stream between the two. Does this
> seem like a OK way to do this? Or is there a better way using socket
> programming (not GLADE).
>
> Now there is two ways of doing this as I see it.
>
>    Should App_B and Server_B keep an open connection at all time so that
>    Server_B can tell App_B to contact App_A?
>
>    If Server_B or App_B is closed at some point then App_B can try to
>    connect again as it can see that the socket when down.
>
>    Or
>
>    Should App_B contact Server_B on startup and say hi I am user ZZZZ
>    you can contact me on port YYYY and then close the connection so that
>    Server_B only contact port YYYY when needed?
>
>    The latter can be a bit problematic if App_B is closed and opened
>    again. Another problem is if the Server_B is closed and opened again
>    as it then looses all the port numbers and username.
>
> App_A and App_B must be run at all time so that the user can either
> recieve or send requests.
>
> Thanks for any hints in advance.
>
> (I'm using GNAT 3.14p with AdaSockets)
> --
> Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
>                  �For me, Ada95 puts back the joy in programming.�

Re: Question on Client - Server communication

[Fabien Garcia]

hi,

This is indeed an old problem of communication, just as you need to know
the phone number of a person you want to talk to, you need the pair 
<address;port> of the application you want to talk to. Most applications
use fixed port (in which case you have only one application server on 
each computer) like FTP and HTTP do. An other way if you want several
application servers on a computer (which seems to be your case) is to
make a directory server.

I think the best way to handle this is to have a directory server on
each machine that waits on a known port (say S_PORT), each time an
application starts, it sends the port it is using to the local server
(through a connection to port S_PORT) and then close the connection.
When an application stops, it send a resignation message to the server
to. In order to avoid problems with server crashs, the server as to
write its configuratio in a file so as not to lose everithing.
each tome application A on computer Ca wants to talk to application B
on computer Cb, it contacts the remote server on Cb and asks for the
port used by application B. This solution make the hypothesis that
an application knows the computer on which the remote application runs,
if this is not the case, you have to make a global server to handle all
the associations <application;address;port>.

I hope this will be usefull, however I do not have any code that does this.

Fabien Garcia

Re: Question on Client - Server communication

[Lutz Donnerhacke]

* Fabien Garcia wrote:
>I hope this will be usefull, however I do not have any code that does this.

man portmapper.

Re: Question on Client - Server communication

[Fabien Garcia]

Lutz Donnerhacke wrote:

> * Fabien Garcia wrote:
> 
>>I hope this will be usefull, however I do not have any code that does this.
> 
> man portmapper.
> 
Yup.

On unixes only, and if firewalls are not on the way.

Re: Question on Client - Server communication

[Lutz Donnerhacke]

* Fabien Garcia wrote:
>Lutz Donnerhacke wrote:
>> * Fabien Garcia wrote:
>>>I hope this will be usefull, however I do not have any code that does this.
>> 
>> man portmapper.
>
>On unixes only,

No, but irrelevant. You looked for a source code. You have one.

>and if firewalls are not on the way.

Real firewall systems understand the protocols they are screening.

Re: Question on Client - Server communication

[John McCabe]

On Fri, 5 Jul 2002 10:08:18 +0200, Preben Randhol
<randhol+ada@pvv.org> wrote:

What you seem to want is something like an Object Resource Broker.
It's probably worth looking at some CORBA documentation to see if it
gives you any ideas.

I did something similar a couple of years ago. This involved what I
called a Resolver - a client would ask the resolver for information on
which port to connect a service on. The resolver would provide this
information. The Resolver would always on the client's local machine.
Servers would register themselves with the Resolver, also on their
local machine. There would be 2 different types of resolver, but
clients and servers would not be aware of this. One type of resolver
would maintain the database of services (and allocate port numbers as
required), and would be queried by the other type of resolver when it
needed some information, so the resolver was always on a known port.
Where the information came from (i.e. the local resolver or the remote
resolver after a query by the local resolver) would be completely
transparent to any clients or servers that were running.

From what I can tell this was a huge simplification of what goes on if
you use CORBA, but worked for what we needed at the time.

How you do the communication between your clients/servers and their
local resolver is pretty much up to you.

Hope this is of use.

Re: Question on Client - Server communication

[Thierry Lelegard]

Preben Randhol wrote :
> 
> I'm doing a small program to learn a bit about socket programming with
> clients and servers. Besides I need the program.
> 
> What I want is an application that can talk to the same application
> running on a different machine. This is ok and no problem. However I
> cannot know the port the application is listening to (there may be
> several users runnig the same application on the same machine).
> Therefore in order to contact the other application I need a server
> running on each machine with a known port number. Then I can do this (_A
> = on machine A, _B on machine B): App_A contacts Server_B which tells
> App_B to contact App_A on port XXXX. So Server_B will only deliver this
> message to App_B and not the whole stream between the two. Does this
> seem like a OK way to do this? Or is there a better way using socket
> programming (not GLADE).

What you describe already exists, this is the portmapper server (port 111).

We have the same problem as you and we use the portmapper for all
our applications.

A portmapper exist on all UNIXen and VMS. For Windows (a so-called OS
which does nothing like the others), we are written a simple portmapper
daemon. Writing a portmapper daemon is trivial. The only tricky part (on
both client and server side) is the underlying protocol based on Sun RPC
and XDR.

See the following references:

RFC 1057 : RPC, Remote Procedure Call Protocol Specification, Version 2
(Appendix A describes the Portmapper interface).

RFC 1014 : XDR, External Data Representation Standard.

-Thierry

Re: Question on Client - Server communication

[Robert A Duff]

Thierry Lelegard <thierry.lelegard@canal-plus.fr> writes:

> A portmapper exist on all UNIXen and VMS.

How do I find it?  Saying "man portmapper" on my solaris system doesn't
find anything.

- Bob

Re: Question on Client - Server communication

[David C. Hoos, Sr.]

I don't have a Solaris system handy at home, but the program
name (and man page) should be "portmap"


----- Original Message ----- 
From: "Robert A Duff" <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: July 06, 2002 6:19 PM
Subject: Re: Question on Client - Server communication


> Thierry Lelegard <thierry.lelegard@canal-plus.fr> writes:
> 
> > A portmapper exist on all UNIXen and VMS.
> 
> How do I find it?  Saying "man portmapper" on my solaris system doesn't
> find anything.
> 
> - Bob
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: Question on Client - Server communication

[Caffeine Junky]

On Fri, 05 Jul 2002 04:08:18 -0400, Preben Randhol wrote:

> I'm doing a small program to learn a bit about socket programming with
> clients and servers. Besides I need the program.
> 
> What I want is an application that can talk to the same application
> running on a different machine. This is ok and no problem. However I
> cannot know the port the application is listening to (there may be
> several users runnig the same application on the same machine).
> Therefore in order to contact the other application I need a server
> running on each machine with a known port number. Then I can do this (_A
> = on machine A, _B on machine B): App_A contacts Server_B which tells
> App_B to contact App_A on port XXXX. So Server_B will only deliver this
> message to App_B and not the whole stream between the two. Does this
> seem like a OK way to do this? Or is there a better way using socket
> programming (not GLADE).

Use port "forwarding". Very simple.

The server designates a standard port. The application connects to the
server on that port. The server then tells the application to switch to
port number X and opens a connection on that port. This leaves the
original port open to recieve more app requests. There are alot of
servers that do this. Check out thier source code.

Apache comes to mind.


St4pL3

Re: Question on Client - Server communication

[Preben Randhol]

Caffeine Junky <nospam@hotmail.com> wrote on 06/07/2002 (03:12) :
> Use port "forwarding". Very simple.
> 
> The server designates a standard port. The application connects to the
> server on that port. The server then tells the application to switch to
> port number X and opens a connection on that port. This leaves the
> original port open to recieve more app requests. There are alot of
> servers that do this. Check out thier source code.

I see. Is this a way to avoid using tasks? I mean I can easily connect
several applications to the same port on a server using tasks.

-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: Question on Client - Server communication

[Caffeine Junky]

On Sat, 06 Jul 2002 15:55:11 -0400, Preben Randhol wrote:

> Caffeine Junky <nospam@hotmail.com> wrote on 06/07/2002 (03:12) :
>> Use port "forwarding". Very simple.
>> 
>> The server designates a standard port. The application connects to the
>> server on that port. The server then tells the application to switch to
>> port number X and opens a connection on that port. This leaves the
>> original port open to recieve more app requests. There are alot of
>> servers that do this. Check out thier source code.
> 
> I see. Is this a way to avoid using tasks? I mean I can easily connect
> several applications to the same port on a server using tasks.
 
Well...depends on what your doing with the tasks. If the tasks are
generating alot of traffic, it might simplify things to tack on an
additional port per Y number of tasks. i.e. Open another port for every
10 tasks. This way the timing issues should be less troublesome.
You also should be familiar with the way the intended platform will
handle the tasks, i.e. as threads or full weight processes, etc...

St4pL3

Re: Question on Client - Server communication

[Craig Carey]

On Sun, 07 Jul 2002 02:37:43 GMT, Caffeine Junky <nospam@hotmail.com>
   wrote:

>On Sat, 06 Jul 2002 15:55:11 -0400, Preben Randhol wrote:
>
>> Caffeine Junky <nospam@hotmail.com> wrote on 06/07/2002 (03:12) :
>>> Use port "forwarding". Very simple.
>>> 
>>> The server designates a standard port. The application connects to the
>>> server on that port. The server then tells the application to switch
>>> to port number X and opens a connection on that port. This leaves the

It is better to not switch to a different port numbers.


>>> original port open to recieve more app requests. There are alot of

It remains open anyway. There can be one call to "bind()" where the port
number is given, and then many calls for to accept() for each TCP thread.
Port forwarding does not have switching to port numbers.

To have a single listening port number, can mean that code to strip off
headers is needed.

I have free source code that removes HTTP/1.0 headers like a client or a
webserver does: it is simple code that would need a bit of rewriting:

http://www.ijs.co.nz/code/ada95_strings_http_hdrs.zip

(That file contains a usable experimental replacement for Ada's
 Unbounded Strings package. It is an improvement.)


...
>Well...depends on what your doing with the tasks. If the tasks are
>generating alot of traffic, it might simplify things to tack on an
>additional port per Y number of tasks. i.e. Open another port for every
>10 tasks. This way the timing issues should be less troublesome.
...

Caffeine might wish that the word "timing" was replaced with: "ordering".
Also, adding unnecessary complexity does not simplify.

It sounds like an interesting project (now that I saw another message
 to CLA saying that Ada tasking and XFree86 (GtkAda too?) are somehow
 incompatible). I didn't catch all the details.