Helen,

> Dmitry, Process X, a Classic instance, signals it is listening for an event. The server side of the process creates the event table and starts broadcasting on port 12345...

The server process never broadcasts. It's connected to a single client
only. See below.

> Then, Process Y signals it is listening for the same event. Now, its event callback will be delivered from the same aux port?
>
> So what I'm asking is - does each Classic process check for the existence of the events table? i.e. the existence of the events table is independent of any particular Classic process? How does Process Y know which port to broadcast from?

If some client registers its interest in any event, the secondary
channel is established between these two endpoints (client and the
server process A it's attached to). It means that the port (e.g. 12345)
enters the listening state for a very short time and then is marked as
connected. If worker process B then issues POST_EVENT and commits, it
modifies the shared event table, so that process A sees the change,
checks whether it needs to deliver a callback and does so via the
aforementioned its own secondary channel. Then if process C registers
the interest in any event, it gets its own secondary channel, also
monitors the shared memory and delivers the necessary callbacks via the
secondary channel. It has no idea what port numbers were used by the
process A and it doesn't actually care, because the port number is sent
to the client in the response packet, i.e. it could be an individual one
per every client connection (this is why random ports works okay).
Theoretically, it could be done via the same port 12345, as process C is
allowed to listen on it again because the process A is not listening
anymore (its endpoint is in the connected state). But obviously, it
would require us to add a cross-process serialization (with timeouts)
for the duration of establishing a secondary connection.


Dmitry