d88-jwa@nada.kth.se (Jon W{tte) (09/23/89)
Wow, here's an almost straightforward, though still-advanced question ! I am currently considering using message queues for a game I'm writing. The problem is: when I create a message queue, I pass a (hopefully) unique 32-bit key. How do I make SURE this key is unique ? (I need to compile the key into a server as well as a client...) I suppose I could use a "setup file" with a precompiled path, and have the server establish an unused key when it first is started, but that idea doesn't appeal to me that much, I'm afraid... Is there anywhere where you register your 32-bit key to ensure that it is unique and noone else uses it ? Or do I use one (presently I'm using 8273460...) and hope noone else uses the same ? Apple Computer has a scheme where you register "file creator types" (also 32-bit longs) to ensure that no two applications get the same icons or conflict with each other's documents. h+@nada.kth.se -- Don't hate yourself in the morning -- sleep till noon.
cpcahil@virtech.UUCP (Conor P. Cahill) (09/24/89)
In article <1747@draken.nada.kth.se>, d88-jwa@nada.kth.se (Jon W{tte) writes: > I am currently considering using message queues for a game I'm writing. > The problem is: when I create a message queue, I pass a (hopefully) > unique 32-bit key. How do I make SURE this key is unique ? (I need to > compile the key into a server as well as a client...) There is no way to "register" or reserve an IPC key value. Most software that I have seen using ipc's has used one of the following: 1. have the initial process obtain a "private" IPC and write the IPC id into a file that is read by all other programs using the IPC. Note that this is better than selecting an unused key because you don't have to hunt around. 2. Use a control file that has the specified key. 3. #2 but allow for an override by an environment variable. 4. hard code in a specific key and hope you don't collide. This is the worst solution. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
guy@auspex.auspex.com (Guy Harris) (09/24/89)
>There is no way to "register" or reserve an IPC key value. Most software >that I have seen using ipc's has used one of the following: > > [methods 1, 2, 3, and 4] 5. Pick some file as a "rendezvous" point, and use "ftok". To quote the SunOS 4.0 version of the "ftok" manual page: All interprocess communication facilities require the user to supply a key to be used by the msgget(2), semget(2), and shmget(2) system calls to obtain interprocess communication identifiers. One suggested method for forming a key is to use the ftok() subroutine described below. Another way to compose keys is to include the project ID in the most signi- ficant byte and to use the remaining portion as a sequence number. There are many other ways to form keys, but it is necessary for each system to define standards for forming them. If some standard is not adhered to, it will be possi- ble for unrelated processes to unintentionally interfere with each other's operation. Therefore, it is strongly sug- gested that the most significant byte of a key in some sense refer to a project so that keys do not conflict across a given system.
d88-jwa@nada.kth.se (Jon W{tte) (09/24/89)
In article <1196@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <1747@draken.nada.kth.se>, d88-jwa@nada.kth.se (Jon W{tte) writes: > 1. have the initial process obtain a "private" IPC and write the > IPC id into a file that is read by all other programs using the > IPC. Note that this is better than selecting an unused key > because you don't have to hunt around. But getting a (process-) "private" key, and then using it in a non-private manner is strictly against my style and image as programmer :-) > 2. Use a control file that has the specified key. > 3. #2 but allow for an override by an environment variable. I now strongly cosider having the make file hunt down an unused key, and save it in a configuration file. Override in an environment variable isn't a bad idea at all; this would allow for multiple games (Good on very large, very game-oriented systems, i.e. universitys :-) Happy hacking ! h+@nada.kth.se -- Life's a bitch, then you die.
prc@erbe.se (Robert Claeson) (09/25/89)
In article <1747@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: >I am currently considering using message queues for a game I'm writing. >The problem is: when I create a message queue, I pass a (hopefully) >unique 32-bit key. How do I make SURE this key is unique ? (I need to >compile the key into a server as well as a client...) I asked about the same question about 1/2 year ago. The summary of the respones were, that queues (and semaphores and shared memories) should be created with the IPC_PRIVATE key. This forces a new queue to be created. The queue id that I then get can be passed on the command-line to subprocesses that are created (I originally needed this for a terminal driver that I'm still writing). Some people mentioned a "ftokey()" function. I didn't investigate it. From the descriptions that I got, it didn't seem that ftokey is guaranteed to return a unique key. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
gil@banyan.UUCP (Gil Pilz@Eng@Banyan) (09/27/89)
In article <1747@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: >I am currently considering using message queues for a game I'm writing. >The problem is: when I create a message queue, I pass a (hopefully) >unique 32-bit key. How do I make SURE this key is unique ? (I need to >compile the key into a server as well as a client...) The usual method for "solving" this is to use the ftok() library call (documented in stdipc(3C)). It takes a pathname and an "id" and spits out a "unique" key for that pair. Your client and server then just have to agree upon an existing, readable file to work off of and a common "id" (0 usually) and they'll be using the same key. >Is there anywhere where you register your 32-bit key to ensure that it >is unique and noone else uses it ? Or do I use one (presently I'm using >8273460...) and hope noone else uses the same ? As stdipc(3C) documents, there is no way to "secure" a key value such that another process can't use it. However when you do use ftok() you end up with these large key values that other, innocent programs are unlikely to stumble upon (like the one you picked). Furthermore, if everyone on your system wore white hats and always used ftok() ;-) you could be sure that nobody would ever step on anybody elses IPC object unless they had access to and picked the same file which brings the whole thing back to the realm of UNIX file names which is where the IPC objects should have been placed in the FIRST place but there you are . . . Also, since they're often overlooked, I'd like to point out the existence of the ipcrm(1) and ipcs(1) utilities. They come in handy when you're trying to debug programs using the IPC stuff. -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Gilbert W. Pilz Jr. gil@banyan.com Banyan Systems Inc. (617) 898-1196 115 Flanders Road Westboro, MA 01581 -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-