Hi Christian,
Right, the current Jonathan RTP implementation is "minimal". As you explained,
it mainly adds some normative header information and that's it.
I was a bit disapointed when I realized, few month ago for internal purposes,
that I had to implement (with pain) my own frag/defragmentation protocol. The
algorithm itself is not complex. The challenge is to avoid useless and costly
"System.arraycopy(...)". Fortunately, Jonathan provides a nice JChunkFactory
which help me a lot to do that. You also have to pay attention (on the decoder
side if the underlying communication channel is unreliable) that olds pending
fragments can lead to memory leaks.
If nedeed, I can try to propose as a contribution an updated version of RTP that
handle Frag/defragmentation (probably not, question of time, before the next
release 3 of Jonathan).
Taking a look on the current RTP implementation, I agree with you that the use
of "UnMarshaller.close()" is quit strange. First, I don't see any particular
reason to make a close and anyway, the place to do that is certainly not after
sending the UnMarshaller to the upper layer (which is now responsble for
closing, reading, reset... on it).
Same thing for the Javadoc which state that the RTP implementation fragments
messages (false) and that it is an invocation protocol (false, it has a one way
semantic). This can be very easily updated.
Nicolas
Per Christian Nodtvedt wrote:
> And here he goes again, the Grand Questioner....
>
> As answers and solutions constantly show up, we steadily move on through the
> landscape of Jontahan to discover new gems of programmatical complexity.
> Now it's time for the RTPProtocol.
>
> Where is the code that fragments and reassembles packets that are larger
> than the underlying protocol's MTU? I've taken a look at the code, and I
> find that a nice header with lots of information gets written in the
> prepare() method in the RTPCoder, but nowhere do I see code that takes a big
> packet and makes lots of small ones from it.
>
> Same goes on the receiving side. The decode() reads the header and passes
> the message up the pile of Session_Low stack, but I see no evidence of
> reassembling.
>
> I noticed that the javadoc says that the implementation is incomplete. Is
> this part of the incompleteness? It also seems to me that the use of
> UnMarshaller.close() is a tad bit aggressive in RTPDecoder.send(), is this
> intended? Or have I misunderstood where to use close()? Isn't the last
> recipent of the UnMarshaller responsible for it's closing?
>
> Another point regarding the javadoc; it says that the protocol is an
> invocation protocol. Nonetheless, the aptly named isAnInvocationProtocol()
> method returns false. I find this a bit strange...
>
> Thank you for your attention,
> Per Christian Nodtvedt, who feels like he's nagging while asking all these
> detailed questions about the protocols.
>
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe jonathan".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonathan".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
