Add support for large blob exchange between client and server

[fritzprix]

Add support for large blob exchange between client and server

[fritzprix]

[fritzprix]

only a blob parameter or response per method is allowed.

allowed example

    Response<Long> postMediaFile(@Body(name = "media") BlobSession media);
    Response<BlobSession> getMediaFile(@Query(name = "id") Long id);

Not allowed example

    // there are two blob parameters 
    Response<Long> postMediaFile(@Body(name = "media") BlobSession media, @Query(name="another") BlobSession anotherMedia);    
    // there are blob parameter and response simultaneously 
    Response<BlobSession> getMediaFile(@Query(name = "id") Long id, @Body(name = "media") BlobSession media)    

[fritzprix]

Blob is sent following after CHUNK SessionControlMessage and will be

• full size chunk is size of 64 kbytes
• end with CRLR ("\r\n")
• Chunk Parameter containing seq #, size of chunk in char, type (middle or last)
• if the chunk is not full (is less than max size), it also means the chunk is last one.

[fritzprix]

Proof-of-concept

1. heterogeneous data on a single channel but consider the situation where some of data type handled outside of messaging protocol

   • Pros
     • able to reuse connection already exists
     • compatiable to network protocol which support only 1-to-1 connection (there is no need for multiple connection to handle two heterogeneous types of data)
   • Cons
     • any other RMI request(s) couldn't be handled within session
     • that mean there will be serious amount of bottle neck in request at concurrent invocation secenario.
       • more complexity in design
       • if teardown message for session drops, any other following request will block permanently. -> that means there would be some sort of timeout stratedgy

2. heterogeneous data on a single channel and adopt messaging protocol capable of handling all the data type (including blob) -> example BSON etc,.

3. heterogeneous data on dedicated channel

[fritzprix]

JSON also able to embed byte array on it, however there should be some sort of text encoding / decoding (for example base64) and it makes the size of message larger.
so I don't consider JSON for second option above comment