Board index » delphi » name conflicts (pipes etc)?

name conflicts (pipes etc)?

The following problem is one for which I cannot find a satisfactory answer. If
anyone could suggest something I would be very grateful. (D2 Win95/NT).

The situation is one in which named pipes (or named shared memory) are being
used to communicate between a server and clients. What can I do if the server
starts up only to find that the agreed name is already being used by some
other process? This may seem to have a very low probability but it can happen
- and in situations where users can set the names, the probability may not be
that low (if my experience with password choice is any indication).

It is easy enough for the server to chose a new name, but how to let the
client know? The client may not be active when the server starts up and will
probably be on another computer.

Malcolm

Please e-mail copy of posting if possible as our news feed is VERY unreliable.

 

Re:name conflicts (pipes etc)?


In message <mac.423.323D2...@barry.hsrc.ac.za>, m...@barry.hsrc.ac.za (Malcolm Coulter) said:

Quote
> The situation is one in which named pipes (or named shared memory) are being
> used to communicate between a server and clients. What can I do if the server
> starts up only to find that the agreed name is already being used by some
> other process? This may seem to have a very low probability but it can happen
> - and in situations where users can set the names, the probability may not be
> that low (if my experience with password choice is any indication).

> It is easy enough for the server to chose a new name, but how to let the
> client know? The client may not be active when the server starts up and will
> probably be on another computer.

I'm not quite sure I understand why you have a problem. Either the object name
is (or should ideally be) fixed when the app is compiled, or you have the
situation that individual users may opt to run a copy of the server, which they
will wish to distinguish from other instances.

If the former, I can't honestly see that it's so difficult to come up with a
unique name.

Why not choose a UUID (universally unique ID) as the name of your object? With
a 1-in-2^128 possibility of collision, Microsoft seems to think they are good
enough to use as fixed names. I suspect that the finite probability of failure
due to a UUID clash is very small compared to the probability of failure due
to program bugs or hardware faults!

In the latter case, how is a new server *ever* to be identified to its potential
clients? You must have some mechanism for publishing capabilities when a server
is first installed, so why not recycle that for use when a collision occurs?
This, of course, is leading you into object broker territory...

-----------------------------------------------------------------------
Steve Rencontre               |  st...@dstrip.demon.co.uk (business)
If it works, it's obsolete.   |  steve...@cix.compulink.co.uk (private)
-----------------------------------------------------------------------

Re:name conflicts (pipes etc)?


Quote
m...@barry.hsrc.ac.za (Malcolm Coulter) wrote:
>The following problem is one for which I cannot find a satisfactory answer. If
>anyone could suggest something I would be very grateful. (D2 Win95/NT).
>The situation is one in which named pipes (or named shared memory) are being
>used to communicate between a server and clients. What can I do if the server
>starts up only to find that the agreed name is already being used by some
>other process? This may seem to have a very low probability but it can happen
>- and in situations where users can set the names, the probability may not be
>that low (if my experience with password choice is any indication).
>It is easy enough for the server to chose a new name, but how to let the
>client know? The client may not be active when the server starts up and will
>probably be on another computer.
>Malcolm
>Please e-mail copy of posting if possible as our news feed is VERY unreliable.

I'm not sure why users need to choose pipe names, but taking that
as a given I had the follwing thought:

What if you dedicate one pipe (or serially named set, eg. ending
with 1,2,3 etc...) created by the server for the purpose of
negotiating client setup. A new client instance first tries to
open myServerSessionSetupPipe_0, (e.g.) gets access denied, then tries
myServerSessionSetupPipe_1 and succeeds in getting a full duplex
connection. The client then communicates the users choice of proposed
working pipe name via the setup pipe, and the server says ok, or sorry
choose another. The client presents this to operator, etc. until a
good working pipe name is chosen. Then that is created by the server,
opened by the client, and the setup pipe is closed so it's available
to the next client. You could handle special security options with
multiple passwords via the setup pipe too, and possibly encrypt the
data etc., besides access control on the pipes per se.

If you need to handle multiple simultaneous setup sessions, you could
have the server always create an extra thread with associated pipe
myServerStartup_x as its name, where x is the first available
currently unused slot, and clients could start with myServerStartup_0
and keep bumping N until they found a non-busy or non-existent status
for a setup pipe.

I haven't tried this, but it's what popped into my head, reading your
question. HIH.

Alternatively, you could use a single fast read from a fixed pipe
to get the next available working pipe name, and just synthesize
names uniquely and never reuse the names. E.g., based on server name
plus a 64-bit counter in hex. Or use a fine-grained binary
date/time stamp instead of a counter.

Regards,
Bengt Richter

Other Threads