From: Hendrik S. <po...@he...> - 2010-11-03 20:40:58
|
Am Mittwoch 03 November 2010, 18:48:58 schrieb max ulidtko: > Hendrik Sattler wrote: > >Indeed there is. MODE_SRV is also used as initial value for the mode > >field. Unless you take that obex_t and register as server with it, the > >MODE_SRV does nothing (there is no listening FD so nothing comes in > >this route). MODE_CLI is automatically set once you send a request and > >everything is set back to initial values once that request ends. > > Those nifty details aren't good; the constants should have clear and > not-obscure, not-confusing meaning and usage, shouldn't they? Or else > the development may become a nightmare: one will be obligated to know > all the internal machinery in detail to be able to use it. There are more scary places. > >Exactly which event is the problem here? > > The problem shows up e.g. in the test client; the event OBEX_EV_REQDONE > gets handled in wrong way because of client having > mode==OBEX_MODE_SERVER. I used the following test scenario: > 1) Launch `apps/obex_test/obex_test -i` and make it listen on tcp > loopback > 2) Launch another instance and make it connect to the server > Here is log of such a launch (client side): The commit that changes that behaviour was: commit 356f9c1e2bcf91377b79957e3097ef74147dd808 Author: Marcel Holtmann <ma...@ho...> Date: Mon Aug 28 12:56:36 2006 +0000 Reset the state before calling the event callback diff --git a/lib/obex_client.c b/lib/obex_client.c index e4c01ec..d0cc7b1 100644 --- a/lib/obex_client.c +++ b/lib/obex_client.c @@ -184,6 +184,7 @@ int obex_client(obex_t *self, buf_t *msg, int final) } else { /* Notify app that client-operation is done! */ DEBUG(3, "Done! Rsp=%02x!\n", rsp); + self->state = MODE_SRV | STATE_IDLE; if (self->object->abort) { if (rsp == OBEX_RSP_SUCCESS) obex_deliver_event(self, OBEX_EV_ABORT, self->object->opcode, rsp, TRUE); @@ -192,7 +193,6 @@ int obex_client(obex_t *self, buf_t *msg, int final) } else obex_deliver_event(self, OBEX_EV_REQDONE, self->object->opcode, rsp, TRUE); - self->state = MODE_SRV | STATE_IDLE; } break; > Please let me know what do you think about this and whether should I > update the patch or not. That patch is 4 years old. Most probably nobody noticed because application mostly only implemented either client or master and not both. At least not with the same event callback function. But the right approach for now is to set the state after calling the event function (in more than just that one place) unless Marcel can tell the reason for the patch. > P.S. Could the list moderator please approve my subscription? I don't > receive new messages, have to refresh mailarchive in browser. Ask Zany or Marcel directly. HS |