# PSF-LoginServer - master - net.psforever.objects.guid.actor
PSF - LoginServer - master - net.psforever.objects.guid.actor
Keywords: PSF LoginServer master net.psforever.objects.guid.actor

PSF-LoginServer - master < Back


# Packages

-  package root
  Definition Classes
    root
-  package net
  Definition Classes
    root
-  package psforever
  Definition Classes
    net
-  package objects
  Definition Classes
    psforever
-  package guid
  Definition Classes
    objects
-  package actor
  Definition Classes
    guid
- NumberPoolActor
- Register
- UniqueNumberSystem
- Unregister
-  package key
  Definition Classes
    guid
-  package pool
  Definition Classes
    guid
-  package selector
  Definition Classes
    guid
-  package source
  Definition Classes
    guid

p

net.psforever.objects.guid

# actor

#### package actor


Ordering

1. Alphabetic

Visibility

1. Public
2. Protected

### Type Members

1.  class NumberPoolActor extends Actor

   An `Actor` that wraps around a `NumberPool` and regulates access to it.
   Wrapping around the pool like this forces a FIFO order to requests for numbers from the pool.

   An `Actor` that wraps around a `NumberPool` and regulates access to it.
   Wrapping around the pool like this forces a FIFO order to requests for numbers from the pool. This synchronization only lasts as long as this `Actor` is the only one for the given pool. In the distribution of globally unique identifiers, this is extremely important. `NumberPool`s are used as the primary determination of whether a number is available at any given moment. The categorization of the pool is also important, though for a contextually-sensitive reason.

2.  final case class Register (obj: IdentifiableEntity, name: Option[String], number: Option[Int], callback: Option[ActorRef]) extends Product with Serializable

   A message for accepting object-number registration requests.
   The callback is actually an `ActorRef` to which a `RegisterSuccess` message or a `RegisterFailure` message is sent.

   A message for accepting object-number registration requests.
   The callback is actually an `ActorRef` to which a `RegisterSuccess` message or a `RegisterFailure` message is sent. This is as opposed to what a "callback" is normally - a function.

   obj

     the mandatory object

   name

     the optional name of the number pool to which this object is registered

   number

     the optional number pre-selected for registering this object

   callback

     the optional custom callback for the messages from the success or failure conditions

3.  class UniqueNumberSystem extends Actor

   An `Actor` that wraps around converted `NumberPool`s and synchronizes a portion of the number registration process.

   An `Actor` that wraps around converted `NumberPool`s and synchronizes a portion of the number registration process. The ultimate goal is to manage a coherent group of unique identifiers for a given "region" (`Zone`). Both parts of the UID system sit atop the `Zone` for easy external access. The plain part - the `NumberPoolHub` here - is used for low-priority requests such as checking for existing associations. This `Actor` is the involved portion that paces registration and unregistration.
   A four part process is used for object registration tasks. First, the requested `NumberPool` is located among the list of known `NumberPool`s. Second, an asynchronous request is sent to that pool to retrieve a number. (Only any number. Only a failing case allows for selection of a specific number.) Third, the asynchronous request returns and the original information about the request is recovered. Fourth, both sides of the contract are completed by the object being assigned the number and the underlying "number source" is made to remember an association between the object and the number. Short circuits and recoveries as available on all steps though reporting is split between logging and callbacks. The process of removing the association between a number and object (unregistering) is a similar four part process.
   The important relationship between this `Actor` and the `Map` of `NumberPoolActors` is an "gate." A single `Map` is constructed and shared between multiple entry points to the UID system where requests are messaged. Multiple entry points send messages to the same `NumberPool`. That `NumberPool` deals with the messages one at a time and sends reply to each entry point that communicated with it. This process is almost as fast as the process of the `NumberPool` selecting a number. (At least, both should be fast.)

4.  final case class Unregister (obj: IdentifiableEntity, callback: Option[ActorRef] = None) extends Product with Serializable

   A message for accepting object-number unregistration requests.

   A message for accepting object-number unregistration requests. When given to a number pool (`NumberPoolAccessorActor`), that `Actor` assumes itself to have the object. When given to a hub object (`NumberPoolHubActor`), it will attempt to determine which pool currently has the object.
   The callback is actually an `ActorRef` to which a `RegisterSuccess` message or a `RegisterFailure` message is sent. This is as opposed to what a "callback" is normally - a function.

   obj

     the mandatory object

   callback

     the optional custom callback for the messages from the success or failure conditions

### Value Members

1.  object NumberPoolActor
2.  object Register extends Serializable
3.  object UniqueNumberSystem
4.  object Unregister extends Serializable

### Ungrouped