Why when I run `$ ipcs` are all shared memory segment keys "0x00000000"?

Question

So when I run $ ipcs, the shared memory segment section returns a variety of results:

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 524288     jvn        600        524288     2          dest         
0x00000000 1048577    jvn        600        524288     2          dest         
0x00000000 1769474    jvn        600        393216     2          dest         
0x00000000 753667     jvn        600        524288     2          dest         
0x00000000 1146884    jvn        600        16777216   2         

The 0x00000000 value is present in every IPC object, why does it not differ? What does it mean?

To provide more context, the TLDP states:

To obtain a unique ID, a key must be used. The key must be mutually agreed upon by both client and server processes. This represents the first step in constructing a client/server framework for an application.

When you use a telephone to call someone, you must know their number. In addition, the phone company must know how to relay your outgoing call to its final destination. Once the other party responds by answering the telephone call, the connection is made.

In the case of System V IPC facilities, the telephone'' correllates directly with the type of object being used. The phone company'', or routing method, can be directly associated with an IPC key.

The key can be the same value every time, by hardcoding a key value into an application. This has the disadvantage of the key possibly being in use already. Often, the ftok() function is used to generate key values for both the client and the server.

Answer 1

Found the answer through a course online, from the Linux Foundation Certified Sysadmin content:

Note almost all of the currently running shared memory segments have a key of 0 or 0x00000000 (also known as IPC_PRIVATE) which means they are only shared between processes in a parent/child relationship.