From: Hendrik S. <po...@he...> - 2010-11-09 08:45:28
|
Zitat von "hui li" <nam...@gm...>: > 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. What is that OBEX_MT_* stuff in your patch? Not SRM, that's clear. HS |