Hi

I need to rewrite a single-user application into a multi-user
version. For this, I'll have to run a server process on a host
somewhere on their LAN.

Since the users aren't very technical, I'd like to make this as easy
as possible, and that includes locating the host acting as the server,
and finding the port number on which it's listening for queries.

Clients could use a broadcast to locate the server... but for this to
work, the server must be able to listen on a specific port... which
might not be available. Catch22.

Is there a solution to this, or do I have to...
1. launch the server on a port, and if it's not available, try another
one at random until it finds one that's available, and display the
port it's listening on in the interface so users can tell
2. launch the client to connect to the default port, and if it can't
connect, tell users to walk to the host that's acting as server, read
the port it's listening on, and type it manually in the client?

Thank you.

In article <necgc39o1cle0u1g6iulsq8toln2g21m49@4ax.com>,
Gilles Ganault <nospam@nospam.com> wrote:

> Hi
>
> I need to rewrite a single-user application into a multi-user
> version. For this, I'll have to run a server process on a host
> somewhere on their LAN.
>
> Since the users aren't very technical, I'd like to make this as easy
> as possible, and that includes locating the host acting as the server,
> and finding the port number on which it's listening for queries.

My guess is you want to implement zeroconf (google or wikipedia should give
you enough to get started).

In article <necgc39o1cle0u1g6iulsq8toln2g21m49@4ax.com>,
Gilles Ganault <nospam@nospam.com> wrote:

> Hi
>
> I need to rewrite a single-user application into a multi-user
> version. For this, I'll have to run a server process on a host
> somewhere on their LAN.
>
> Since the users aren't very technical, I'd like to make this as easy
> as possible, and that includes locating the host acting as the server,
> and finding the port number on which it's listening for queries.

My guess is you want to implement zeroconf (google or wikipedia should give
you enough to get started).

In article <necgc39o1cle0u1g6iulsq8toln2g21m49@4ax.com>,
Gilles Ganault <nospam@nospam.com> wrote:

> Hi
>
> I need to rewrite a single-user application into a multi-user
> version. For this, I'll have to run a server process on a host
> somewhere on their LAN.
>
> Since the users aren't very technical, I'd like to make this as easy
> as possible, and that includes locating the host acting as the server,
> and finding the port number on which it's listening for queries.
>
> Clients could use a broadcast to locate the server... but for this to
> work, the server must be able to listen on a specific port... which
> might not be available. Catch22.
>
> Is there a solution to this, or do I have to...
> 1. launch the server on a port, and if it's not available, try another
> one at random until it finds one that's available, and display the
> port it's listening on in the interface so users can tell
> 2. launch the client to connect to the default port, and if it can't
> connect, tell users to walk to the host that's acting as server, read
> the port it's listening on, and type it manually in the client?

You could use the portmapper protocol. If the server is a Unix system,
it's most likely running the portmap service.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

On Sun, 19 Aug 2007 18:03:26 -0400, Roy Smith <roy@panix.com> wrote:
>My guess is you want to implement zeroconf (google or wikipedia should give
>you enough to get started).

Thanks guys. Forgot to mention 1) it's an all Windows context so
portmap won't do, 2) I'd rather minimize setup, so deploying
zeroconf/bonjour is too much work.

For those interested in doing the same thing, elsewhere, someone
mentionned using NetBIOS to register a name on the server so that
clients can locate it through a broadcast, and then use named pipes to
actually TX/RX data. I was thinking of just having the server send the
IP port on which it's listening, but named pipes might be good enough
to also send real data once the two hosts are connected.

Thank you.

On Aug 20, 4:59 am, Gilles Ganault <nos...@nospam.com> wrote:
> On Sun, 19 Aug 2007 18:03:26 -0400, Roy Smith <r...@panix.com> wrote:
> >My guess is you want to implement zeroconf (google or wikipedia should give
> >you enough to get started).
>
> Thanks guys. Forgot to mention 1) it's an all Windows context so
> portmap won't do, 2) I'd rather minimize setup, so deploying
> zeroconf/bonjour is too much work.
>
> For those interested in doing the same thing, elsewhere, someone
> mentionned using NetBIOS to register a name on the server so that
> clients can locate it through a broadcast, and then use named pipes to
> actually TX/RX data. I was thinking of just having the server send the
> IP port on which it's listening, but named pipes might be good enough
> to also send real data once the two hosts are connected.
>
> Thank you.

Why not do what the normal DHCP protocol does..
i.e.

1) Make the client application send a broadcast.
2) Let the server reply back with the IP / port no.

This of course assumes a couple of things
1) You can modify the client program to implement this protocol.
2) Client & server resides on the same LAN (in the absence of
proprietary relay agents on routers)


--Debashis Dutt

On Aug 20, 4:59 am, Gilles Ganault <nos...@nospam.com> wrote:
> On Sun, 19 Aug 2007 18:03:26 -0400, Roy Smith <r...@panix.com> wrote:
> >My guess is you want to implement zeroconf (google or wikipedia should give
> >you enough to get started).
>
> Thanks guys. Forgot to mention 1) it's an all Windows context so
> portmap won't do, 2) I'd rather minimize setup, so deploying
> zeroconf/bonjour is too much work.
>
> For those interested in doing the same thing, elsewhere, someone
> mentionned using NetBIOS to register a name on the server so that
> clients can locate it through a broadcast, and then use named pipes to
> actually TX/RX data. I was thinking of just having the server send the
> IP port on which it's listening, but named pipes might be good enough
> to also send real data once the two hosts are connected.
>
> Thank you.

Why not do what the normal DHCP protocol does..
i.e.

1) Make the client application send a broadcast.
2) Let the server reply back with the IP / port no.

This of course assumes a couple of things
1) You can modify the client program to implement this protocol.
2) Client & server resides on the same LAN (in the absence of
proprietary relay agents on routers)


--Debashis Dutt

On Aug 19, 8:18 am, Gilles Ganault <nos...@nospam.com> wrote:
> Hi
>
> I need to rewrite a single-user application into a multi-user
> version. For this, I'll have to run a server process on a host
> somewhere on their LAN.
>
> Since the users aren't very technical, I'd like to make this as easy
> as possible, and that includes locating the host acting as the server,
> and finding the port number on which it's listening for queries.
>
> Clients could use a broadcast to locate the server... but for this to
> work, the server must be able to listen on a specific port... which
> might not be available. Catch22.
>
> Is there a solution to this, or do I have to...
[snip]

Why don't you just execute the "standard practice"?
- On the server, hardcode the logic to watch a specific port (or
service name). Use one that you know (or are reasonably certain) is
not in use by another server.

- On the client, hardcode the logic to connect to the same specific
port that you selected for your server.