« Return to Thread: Possible libsyncml MoreData bug?
Re: Possible libsyncml MoreData bug?
by Michael Bell
::
Rate this Message:
Michael Bell schrieb:
> Michael Bell schrieb:
>> Josh Guilfoyle schrieb:
>
>>> Specifically, it looks like any time <MoreData> is sent by libsyncml
>>> (and acknowledged by the receiver by way of a 214 status), the
>>> following SyncML message starts the item from the beginning, so a
>>> compliant SyncML client would append the item's contents to some part
>>> of the item from the previous message.
>>
>> Ticket #1.
>
> The code to handle too large items is in sml_session.c. The function is
> called _smlSessionStartCommandInternal. Another suspect is the function
> _smlSessionFragmentSend and all of its callers because it handles the
> splitting of a command.I discovered two things in _smlSessionFragmentSend until now:
1. Why does a parameter complete_size exists if the size of the item is
determined dynamically in the function?
2. If a new command is created to send the beginning of a splitted
command then there is the following line:
if (start == 0)
frag_cmd->size = complete_size;
This means that the size of the new command is set to the original (too
large) size.
Perhaps I need more time to understand the code but these are the first
things which I discovered. Perhaps somebody knows this part of the code
a little bit better than I.
Best regards
Michael
P.S. do you have a wireshark trace of such a failing conversation?
--
_______________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice
Fax: +49 (0)30-2093 2704 Unter den Linden 6
michael.bell@... D-10099 Berlin
_______________________________________________________________
X.509 CA Certificates / Wurzelzertifikate
http://ra.pki.hu-berlin.de
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel
> Michael Bell schrieb:
>> Josh Guilfoyle schrieb:
>
>>> Specifically, it looks like any time <MoreData> is sent by libsyncml
>>> (and acknowledged by the receiver by way of a 214 status), the
>>> following SyncML message starts the item from the beginning, so a
>>> compliant SyncML client would append the item's contents to some part
>>> of the item from the previous message.
>>
>> Ticket #1.
>
> The code to handle too large items is in sml_session.c. The function is
> called _smlSessionStartCommandInternal. Another suspect is the function
> _smlSessionFragmentSend and all of its callers because it handles the
> splitting of a command.
1. Why does a parameter complete_size exists if the size of the item is
determined dynamically in the function?
2. If a new command is created to send the beginning of a splitted
command then there is the following line:
if (start == 0)
frag_cmd->size = complete_size;
This means that the size of the new command is set to the original (too
large) size.
Perhaps I need more time to understand the code but these are the first
things which I discovered. Perhaps somebody knows this part of the code
a little bit better than I.
Best regards
Michael
P.S. do you have a wireshark trace of such a failing conversation?
--
_______________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice
Fax: +49 (0)30-2093 2704 Unter den Linden 6
michael.bell@... D-10099 Berlin
_______________________________________________________________
X.509 CA Certificates / Wurzelzertifikate
http://ra.pki.hu-berlin.de
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel
smime.p7s (7K) « Return to Thread: Possible libsyncml MoreData bug?
| Free Forum Powered by Nabble | Forum Help |
