Am Mittwoch 10 November 2010, 00:05:10 schrieb Hendrik Sattler: > Am Dienstag 09 November 2010, 22:49:10 schrieb Hendrik Sattler: > > Am Dienstag 09 November 2010, 09:45:19 schrieb Hendrik Sattler: > > > Zitat von "hui li" <nami.li1...@gmail.com>: > > > > Thans a lot for your mail. The obex15 spec says "SRM shall be used > > > > for all multi-response operatons(PUT and GET) for the duration of > > > > the SRM mode". I don`t know why you think SRM only valid in PUT > > > > request and GET response in my branch. I handled both server and > > > > client side during SRM. > > > > > > > > For SRM PUT request ,client keeps sending request containing body > > > > to > > > > > > > > server without server response ,and server only responses at the > > > > first request, the last put request or abort request. For SRM GET > > > > request, server keeps sending responses containing body to client > > > > without client other request ,and client only send first SRM GET > > > > request or abort request. > > > > My brach simply assumes only client can request SRM enble firstly, > > > > if server receives SRM header, it responses SRM enable. On a put or > > > > get operation, server does not request SRM in its head initiatively. > > > > > > > > I will study your queue without threading later. > > > > > > I will publish it (not done, yet). The idea is to make > > > OBEX_HandleInput() not call obex_transport_handle_input() but a new > > > function obex_work() instead which call one of the new function > > > obex_(client|server)_work(). In those, it is easy to see in which > > > state a response will not come and a packet has to be sent without it. > > > Omitting more than one response(server) or additional requests(client) > > > is easily done inline. > > > I will post a proposal patch this evening so everybody can comment. It > > > will leave handling of all OBEX SRM headers to the application so it > > > can decide if it trusts the transport enough to enable it. > > > > Here it is. Note that the write()/send() functions still fail too easily. > > That's needs to be solved, I'll do that the next days. > > > > What's in it: > > - allows to handle SRM mode > > - removes STATE_IDLE which was only used in MODE_CLI (now handled by > > STATE_SEND) > > - changes rx_msg buffer management so that a message stream is handled > > correctly > > > > You can test it easily with any application by initialising > > self->rsp_mode to OBEX_RSP_MODE_SINGLE instead of OBEX_RSP_MODE_NORMAL. > > Ups, a error crept in. Here is another version.
You can find it now in my repository: http://www.gitorious.org/openobex/mainline/commits/for-mainline I splitted it into several patches. HS ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
