Provides the interface to the Project Darkstar Server.

Implementation-specific information

Configuration properties

See this document for a list of configuration properties supported by the current implementation of the Project Darkstar Server.

Additional Protocol Semantics

In addition to the semantics for protocol messages given in {@link com.sun.sgs.protocol.simple.SimpleSgsProtocol}, the current implementation of the Project Darkstar Server provides the following semantics for messages:

If a Project Darkstar server receives a message with an Opcode other than those specified in the protocol specification, or with an Opcode that defines a message that should only be sent to a client, or the message is malformed in other ways, the server will disconnect the client session that was the origin of the message;
If the server receives a message from a client that is not currently logged in, and the message is not a LOGIN_REQUEST, the message will be ignored;
If the server receives a LOGIN_REQUEST that specifies the same identity as an existing user, the behavior of the server is determined by the value of the com.sun.sgs.impl.service.session.allow.new.login property. If the value of that property is false (the default value) the new login is not permitted and the server responds with a LOGIN_FAILURE. If the value of the property is true, the user's existing session is disconnected, and a new login is allowed to proceed.

At this time, the Project Darkstar Server does not implement a response to the RECONNECT_REQUEST Opcode. The current implementation treats such a request as an unknown Opcode and will disconnect any client sending such a request. Similarly, the current implementation of the Project Darkstar server will not send messages beginning with the RECONNECT_SUCCESS or RECONNECT_FALURE Opcodes.

Modifications and updates to managed objects

You can using logging to obtain information about instances of {@link com.sun.sgs.app.ManagedObject} that were modified without being marked for update. Developers can use this information to help determine if they can safely disable the automatic detection of object modifications — see the documentation for the com.sun.sgs.impl.service.data.DataServiceImpl.detect.modifications property.

Information about managed objects that were modified and not marked for update is logged to the {@link java.util.logging.Logger Logger} named {@code com.sun.sgs.impl.service.data.DataServiceImpl.detect.modifications} at level {@link java.util.logging.Level#FINEST FINEST}. This logging is only performed if detection of modifications is enabled.

API conventions

Interfaces in this API do not extend {@link java.io.Serializable} even if classes that implement those interfaces are required to implement it.

The API uses this approach to avoid an issue involving the serialVersionUID field. To guard against serialVersionUID mismatches, as well as to improve performance, any class or interface that extends Serializable should declare a serialVersionUID field. Since public interfaces can only declare public members, a public interface that extends Serializable would need to have a public serialVersionUID field, meaning that any classes implementing the interface would inherit its serialVersionUID, and so would be prevented from controlling their versioning separately. This issue does not crop up for interfaces that do not extend Serializable, since they by definition have a serialVersionUID of 0.

Documentation conventions

Unless explicitly specified otherwise, all documentation for these APIs uses the following conventions:

If null is not explicitly specified as an acceptable value for a method parameter, then the method does not permit null to be passed as a value for that parameter, and will throw a {@link java.lang.NullPointerException} if null is passed (though it is left unspecified whether or not NullPointerException takes precedence over other types of exceptions that could also be thrown).
If null is not explicitly specified as an acceptable value for a method to return, then the method is not permitted to return null.
If null is not explicitly specified as an acceptable value for a given collection (e.g. {@link java.util.Collection}, {@link java.util.List}, or {@link java.util.Set}) to contain, then the collection is not permitted to contain null elements.

Methods that can accept or return null values generally specify this at least in their parameter-level (i.e. @param tag) or return value-level (i.e. @return tag) documentation.