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