COMP 310 Fall 2015	Lec34:  ChatApp finalization, continued...

For guidance on handling threads, please see the Java Threads Resource page.

How does the receiver of a data packet know who sent it?

Possibilities:

• IUser.receiveData() also takes the sender's IUser stub as an input parameter.
  • Implies that the processing visitor on the receiver must pass the sender's stub as an input parameter.
  • Enables a data packet to be resent from a new user without modification.
• The sender is part of the DataPacket
  • Need to add a getSender() method to DataPacket
  • To resend the data packet would require repackaging the held data into a new DataPacket instance with the correct sender.
  • Changes return type of IChatroom.relayMsg to Iterable<ADatapacket>
• The sender is part of the data in the DataPacket
  • Some (all?) data types must contain the sender.

Unknown Data Type Management Protocol Options:

• If the API requires that the unknown message be resent:
  • Resend message paired with associated command:  A single operation can both install the new command and process the message so no caching of the unknown message is required.
  • Resend the message separately from sending the command:  No caching is required but there is a potential for a race condition if the command is not installed by the time that the resent message is received.
• If the API requires that the unknown message NOT be resent:
  • If the send message process  returns a message:
    • The request for the new command and its return can be handled synchronously, in a single transaction.   Thus the original unknown message does not need to be cached.
  • If the send message process returns a status value:
    • Using messages to request and send the new command:  The request for the new command and the sending of the new command CANNOT be handled synchronously.   Thus the original unknown message needs to be cached. 
    • Using a separate method to request and send the new command:   The request for the new command and its return can be handled synchronously, in a single transaction.  Thus the original unknown message does not need to be cached.  
      • However, this means the addition of an extra method to handle something that, conceptually, should be able to be handled using a message, just to get around the lack of a return value.   The philosophical soundness of this approach should be examined in detail. 
  • If the sending of a message is asynchronous (void return):
    • The request of the the new command and hte sending of the new command are necessarily also sent asynchronously.
      • The reception of the new command is thus handled on a different thread than the original reception of the unknown message and thus the original unknown message needs to be cached. 

Connecting a remotely-sourced command to the local system

Since a command being sent over from a remote system has no idea about the environment of the local system into which it is being installed, it has no intrinsic means in which to display any information on the local UI or interact with the local user or system.     Thus, the local system must give the incoming command a reference to an adapter to the local system where the adapter implements an interface that is part of the common public API.

The question is "What minimal set of operations on this adapter are needed to give the command the most flexibility but minimize its ability to harm the local system?" 

Note that the attachment of this adapter to the incoming command is only ever done once, when the command is first received from the remote sender.   The method that installs the local system adapter, is thus a perfect place for the command to perform any one-time initializations that it needs to do upon its integration into the local system.

QUESTIONS: Should an incoming command

• Be given a reference to the local message receiver stub?
• Be given access to "transmission services", e.g.
  • everyone in the chatroom and/or
  • specific user
    • any user, or
    • only to "call home"  (or can a command do this anyway?)
•  Be given access to the local GUI?  
  • What is the most flexible, safest access?
  • Note that few users like systems that pop up numerous frames for various operations.
• Be given access to any other services?

Important implementation detail: 

Keeping a field value from being serialized:

As per the above API standard, a ADataPacketAlgoCmd implementaion may have a field of type ICmd2ModelAdapter that holds a reference to current adapter.    When a command is transferred from the sender to the receiver, the command may have been already connected to the sender's model via an ICmd2ModelAdapter implementation created by the sender. 

But when the command is sent to the receiver, the receiver will install its own ICmd2ModelAdapter that connects to its own model and view.   It is not necessary or desirable to serialize and transmit the value of the adapter reference  esp. since such adapters are usually anonymous inner classes. 

To tell Java not to serialize and transmit the value of a field, mark the field with the keyword "transient". 

Example:

private transient ICmd2ModelAdapter cmd2ModelAdpt; 

When this the command is deserialized at the receiver, this field will be null.    Thus, you MUST call setCmd2ModelAdpt() on the new command BEFORE it is installed into the data packet processing visitor (e.g. algo.setCmd())!

© 2015 by Stephen Wong