...
There are two candidate framing mechanisms for transporting a single object message over a socket:
CRLF termination
Length-Prefixing
The former is easier to implement but the latter is more efficient for receivers since each byte doesn’t have to be examined one at a time by the network layer, and is also the implementation used in the previous versions with the current protocol. A final determination will depend on testing of exactly how the Spring Integration socket layer actually deals with this since all the current testing has been done with one-off connections that are closed after a single exchange. The only major advantage to CRLF termination is ease of message construction for tests since the length-prefixing is binary data.
Messaging Protocol
The application messaging protocol is layered on top of the DDF data structure by defining conventions for the content of the object in order to represent both the operation to perform target of the message and the input to the operation. The convention is simply that the root object’s name contains the name of the operation endpoint to performreceive the message. Operations Endpoints will have unique names in a manner to be determined. The rest of the object’s content consists of the input to the desired operation and is defined by the operationendpoint and the operations(s) it may support. Operations are defined to return an output object. The output object cannot be null, but may be empty, and the contents are entirely defined by the contract for the operation.
...
Since the implementation of the client and server will now be separated rather than a single code base, there will be more effort to define and document these endpoint names and input contracts as a public API. Generally any data passed beyond that specified can be passed but safely ignored (this also potentially allows pipelines to be built since a message can be transformed and passed along to additional recipients. This hasn’t been done in the SP to this point because the message dispatching process was tightly coupled to the socket processing code, but should be more possible now.
...
The code currently does a lot of verbose conversion work outside the DDF layer to handle time_t data by encoding it to strings using a formatting pattern and then parsing it back. This was mainly to deal with the fact that the size of time_t grew to 64 bits so it wasn’t clear how to handle mismatches in architecture. I would like to change this and add a native DDF type for it, but I’m not sure how to do that. For now, support has been added for 64-bit integers that may work on 32-bit compilers.
There is currently no prefix or magic sequence to deal with versioning, but we may need to add this.