[Css-csts] practical concerns - TransferBuffer

[Yves.Doat at esa.int]

Dear Tim,

The TransferBuffer is not an operation, it is a mechanism to optimise the use
of the communication layer (in our case TCP) so that we do not send many
individual small messages.. To add a header we would have to promote the
definition to an operation that would contain other operations. This new
concept would, I am afraid, have a big impact on the Framework and I am not
sure we would gain a lot.

Removing the standard header for individual operations would be against all
agreements we have had so far, i.e. all operations have a standard header
that ease the decoding.
For information, I looked into the size of the standard header:
   Minimum size: 22 bytes
   Maximum size: around 278 bytes
This approach would also derive from the existing SLE approach.

We can address this point during the next teleconference but I am not in
favour of those changes

Best regards
Yves



                                                                             
             "Ray, Timothy J.                                                
             (GSFC-5830)"                                                    
             <timothy.j.ray at nas                                           To 
             a.gov>                     "css-csts at mailman.ccsds.org"         
             Sent by:                   <css-csts at mailman.ccsds.org>         
             css-csts-bounces at m                                           cc 
             ailman.ccsds.org                                                
                                                                     Subject 
                                        [Css-csts] practical concerns -      
             12/08/2009 23:08           TransferBuffer                       
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             




Dear Working Group,

When a CSTS User receives an incoming TransferBufferInvocation, it has to dig
pretty deep to determine the ProcedureInstanceId.  If it is ever important to
make the User’s processing of incoming data efficient (i.e. so that data can
be transferred at a high data rate), it may be worthwhile to ease the
processing required.  For example, we might consider adding a
ProcedureInstanceId (or StandardInvocationHeader) at the top-level of the
TransferBufferInvocation structure.

Related topic:  If it is ever important to reduce the overhead (bandwidth)
associated with CSTS, it might be worthwhile to reduce the number of
Standard-Invocation-Header appearances in a TransferBufferInvocation.   For
example, currently, if a single TransferBufferInvocation contains 100
TransferDataInvocations, there will be 100 copies of the
StandardInvocationHeader (and thus 100 copies of the Credentials, and 100
copies of the ProcedureInstanceId).

Thoughts towards a possible solution:
When invocations are nested inside another invocation, the
StandardInvocationHeader is only required in the outermost invocation.
The StandardInvocationHeader is optional in the TransferDataInvocation and
NotificationInvocation.

Best regards,
Tim_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts