Skip to content

Update CommunicationRegistration for re usability  #110

@ThorbenKuck

Description

@ThorbenKuck

Description

The CommunicationRegistration should receive a dispatcher core, to allow any using developer to use the CommunicationRegistration without it using the NetComThreadPool. Further, the Connection(Context) and the Session should be nullable or receive a Null-Object-Implementations.

The reason

If you want to use the CommunicationRegistration outside of the context of the Network (i.e. to emulate a network communication, where there is none), you can use this CommunicationRegistration. This however always dispatches a Process to the NetComThreadPool.

Imagine you want a AI on the Server, that receives Objects through an google.guava.EventBus but should act like any other client. This would be one usecase, where the aggregating class (like a Game-Object) only posts DataObjects on an EventBus. A "real" client based user would now send it through the Network. A AI would act now and re-post the result. If you do not use the CommunicatoinRegistration, you would have to manually recreate this class or check manually using if-else if-else (i.e. switch-case). Reusing this CommunicationRegistration makes total sense in such a case.

Example

A Simple evaluation-core should be added, that is used by the CommunicationRegistration. It might look like this:

public interface CommunicationDispatcher {

    /**
      * Handles concrete dispatch requests
      */
    <T> void dispatch(ReceivePipeline<T> pipeline, ConnectionContext context, Session session, T object);

    /**
      * Handle not registered objects.
      * This means, we have handlers and we do not throw NotSpecifiedException
      */
    <T> void notRegistered(ReceivePipeline<Object> pipeline, ConnectionContext context, Session session, T object);
}

There could be two implementations. SynchronousCommunicationDispatcher and AsynchronousCommunicationDispatcher. The names should speak for themself.

The Factory-Methods within the interface should be updated, to the following:

// Old way
CommunicationRegistration registration = CommunicationRegistration.open();

// And now
CommunicationRegistration registration1 = CommunicationRegistration.synchronous();
CommunicationRegistration registration2 = CommunicationRegistration.asynchronous();
// Raw, for the use of custom dispatchers
// The argument dispatcher is of the type "CommunicationDispatcher"
CommunicationRegistration registration3 = CommunicationRegistration.open(dispatcher);
// To not break existing code, the default open method should point to asynchronous
// So, assertEquals(registratio2, registration4) should work
CommunicationRegistration registration4 = CommunicationRegistration.open();

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestThe Issue requests a new featuregood first issueThis lable shows a good point to start, if you are not familiar with NetCom2

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions