2011-06-21 13:44:09

by Piotr Zgórecki

[permalink] [raw]
Subject: SRM support in OBEX

Hi,

Is anybody working on SRM support in obexd ? I might be able to spend
some time on this but would like to avoid duplication of effort if
it's in the pipeline.

Cheers,
Piotr


2011-06-23 12:04:43

by Hendrik Sattler

[permalink] [raw]
Subject: Re: SRM support in OBEX

Am Donnerstag, 23. Juni 2011, 10:31:26 schrieb Luiz Augusto von Dentz:
> I guess he meant that to make this work properly the socket must be
> non-blocking so that OpenOBEX needs to detected when a packet could
> not be written and somehow wake-up the application whenever it can
> resume.

I mean that currently OpenOBEX uses non-blocking sockets like blocking socket
by busy-looping until all data of one packet is written. On slow devices, this
is maybe not wanted, especially when using non-blocking sockets in the first
place :)
The control of re-calling OpenOBEX is still on the application side.

HS

2011-06-23 08:31:26

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: SRM support in OBEX

Hi Nami,

On Thu, Jun 23, 2011 at 11:23 AM, Li, Nami <[email protected]> wrote:
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Hendrik Sattler
> Sent: 2011年6月22日 19:18
> To: Luiz Augusto von Dentz
> Cc: Li, Nami; Piotr Zgórecki; [email protected]; Liu, Haijun; Fan, Hong
> Subject: Re: SRM support in OBEX
>
> Zitat von Luiz Augusto von Dentz <[email protected]>:
>
>> Hi Nami,
>>
>> 2011/6/22 Li, Nami <[email protected]>:
>>> Hi, Piotr
>>>  I worked on SRM several weeks ago but finally stopped.
>>>  It`s easy to set and check SRM header, as well as set the response
>>> mode to OBEX_RSP_MODE_SINGLE. And it is already well supported in
>>> obex_work function when the response mode is SRM, client and server
>>> can continue send data without remote side response or request. The
>>> obex_work callback relationship is:
>>> obex_session_start()
>>>                                        ...
>>>                        g_io_add_watch_full(io, G_PRIORITY_DEFAULT,
>>>     G_IO_IN | G_IO_HUP | G_IO_ERR | G_IO_NVAL,
>>>  obex_handle_input, obex, obex_handle_destroy);
>>>                                        ...
>>> obex_handle_input()
>>>                                        ...
>>>                        OBEX_HandleInput(obex, 1)
>>>                                        ...
>>> OBEX_HandleInput()
>>>                                        ...
>>>                        obex_work(self, timeout);
>>>
>>> The problem in SRM is:
>>> If remote side doesn`t send any data to local side, then the G_IO_IN
>>> condition couldn`t be set. So how obex_work can be called?
>>>
>>> I haven`t found any good solution for this issue. So if you can spend
>>> some time on SRM, I`ll be very happy:)
>>
>> No top posting in this list, please.
>>
>> So back to the topic, we probably need to add another watch with
>> G_IO_OUT when using SRM so that it wake ups whenever we can write to
>> the socket/fd, obviously this should only be active when we are
>> sending data (GET) and there is no need to call OBEX_HandleInput.
>
> You have to call OBEX_HandleInput() for sure. It does the work also for the SRM case. I am also redesigning the state machine in OpenOBEX so that incomplete writes on non-blocking sockets are possible. This feature will be protected by a flag because it creates a small problem like for SRM.
> If you need a function in OpenOBEX that tells you if input-independent writes are needed, just tell me or create one :-)
>
> HS
>
> What do you mean "incomplete writes on non-blocking sockets " and " input-independent writes "? Do you mean to write lots of data one time and use G_IO_OUT to wakeup obex_work?

I guess he meant that to make this work properly the socket must be
non-blocking so that OpenOBEX needs to detected when a packet could
not be written and somehow wake-up the application whenever it can
resume.



--
Luiz Augusto von Dentz

2011-06-23 08:23:09

by Li, Nami

[permalink] [raw]
Subject: RE: SRM support in OBEX

DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsaW51eC1ibHVldG9vdGgtb3du
ZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtYmx1ZXRvb3RoLW93bmVyQHZnZXIua2Vy
bmVsLm9yZ10gT24gQmVoYWxmIE9mIEhlbmRyaWsgU2F0dGxlcg0KU2VudDogMjAxMeW5tDbmnIgy
MuaXpSAxOToxOA0KVG86IEx1aXogQXVndXN0byB2b24gRGVudHoNCkNjOiBMaSwgTmFtaTsgUGlv
dHIgWmfDs3JlY2tpOyBsaW51eC1ibHVldG9vdGhAdmdlci5rZXJuZWwub3JnOyBMaXUsIEhhaWp1
bjsgRmFuLCBIb25nDQpTdWJqZWN0OiBSZTogU1JNIHN1cHBvcnQgaW4gT0JFWA0KDQpaaXRhdCB2
b24gTHVpeiBBdWd1c3RvIHZvbiBEZW50eiA8bHVpei5kZW50ekBnbWFpbC5jb20+Og0KDQo+IEhp
IE5hbWksDQo+DQo+IDIwMTEvNi8yMiBMaSwgTmFtaSA8bmFtaUBxY2EucXVhbGNvbW0uY29tPjoN
Cj4+IEhpLCBQaW90cg0KPj4gwqBJIHdvcmtlZCBvbiBTUk0gc2V2ZXJhbCB3ZWVrcyBhZ28gYnV0
IGZpbmFsbHkgc3RvcHBlZC4NCj4+IMKgSXRgcyBlYXN5IHRvIHNldCBhbmQgY2hlY2sgU1JNIGhl
YWRlciwgYXMgd2VsbCBhcyBzZXQgdGhlIHJlc3BvbnNlIA0KPj4gbW9kZSB0byBPQkVYX1JTUF9N
T0RFX1NJTkdMRS4gQW5kIGl0IGlzIGFscmVhZHkgd2VsbCBzdXBwb3J0ZWQgaW4gDQo+PiBvYmV4
X3dvcmsgZnVuY3Rpb24gd2hlbiB0aGUgcmVzcG9uc2UgbW9kZSBpcyBTUk0sIGNsaWVudCBhbmQg
c2VydmVyIA0KPj4gY2FuIGNvbnRpbnVlIHNlbmQgZGF0YSB3aXRob3V0IHJlbW90ZSBzaWRlIHJl
c3BvbnNlIG9yIHJlcXVlc3QuIFRoZSANCj4+IG9iZXhfd29yayBjYWxsYmFjayByZWxhdGlvbnNo
aXAgaXM6DQo+PiBvYmV4X3Nlc3Npb25fc3RhcnQoKQ0KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAuLi4NCj4+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZ19pb19hZGRfd2F0Y2hfZnVsbChpbywgR19QUklPUklU
WV9ERUZBVUxULA0KPj4gwqAgwqAgR19JT19JTiB8IEdfSU9fSFVQIHwgR19JT19FUlIgfCBHX0lP
X05WQUwsDQo+PiDCoG9iZXhfaGFuZGxlX2lucHV0LCBvYmV4LCBvYmV4X2hhbmRsZV9kZXN0cm95
KTsNCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgLi4uDQo+PiBvYmV4X2hhbmRsZV9pbnB1dCgpDQo+PiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC4uLg0KPj4gwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBPQkVYX0hhbmRsZUlucHV0KG9iZXgsIDEpDQo+
PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoC4uLg0KPj4gT0JFWF9IYW5kbGVJbnB1dCgpDQo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC4uLg0KPj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvYmV4X3dvcmsoc2VsZiwgdGltZW91dCk7DQo+Pg0KPj4g
VGhlIHByb2JsZW0gaW4gU1JNIGlzOg0KPj4gSWYgcmVtb3RlIHNpZGUgZG9lc25gdCBzZW5kIGFu
eSBkYXRhIHRvIGxvY2FsIHNpZGUsIHRoZW4gdGhlIEdfSU9fSU4gDQo+PiBjb25kaXRpb24gY291
bGRuYHQgYmUgc2V0LiBTbyBob3cgb2JleF93b3JrIGNhbiBiZSBjYWxsZWQ/DQo+Pg0KPj4gSSBo
YXZlbmB0IGZvdW5kIGFueSBnb29kIHNvbHV0aW9uIGZvciB0aGlzIGlzc3VlLiBTbyBpZiB5b3Ug
Y2FuIHNwZW5kIA0KPj4gc29tZSB0aW1lIG9uIFNSTSwgSWBsbCBiZSB2ZXJ5IGhhcHB5OikNCj4N
Cj4gTm8gdG9wIHBvc3RpbmcgaW4gdGhpcyBsaXN0LCBwbGVhc2UuDQo+DQo+IFNvIGJhY2sgdG8g
dGhlIHRvcGljLCB3ZSBwcm9iYWJseSBuZWVkIHRvIGFkZCBhbm90aGVyIHdhdGNoIHdpdGggDQo+
IEdfSU9fT1VUIHdoZW4gdXNpbmcgU1JNIHNvIHRoYXQgaXQgd2FrZSB1cHMgd2hlbmV2ZXIgd2Ug
Y2FuIHdyaXRlIHRvIA0KPiB0aGUgc29ja2V0L2ZkLCBvYnZpb3VzbHkgdGhpcyBzaG91bGQgb25s
eSBiZSBhY3RpdmUgd2hlbiB3ZSBhcmUgDQo+IHNlbmRpbmcgZGF0YSAoR0VUKSBhbmQgdGhlcmUg
aXMgbm8gbmVlZCB0byBjYWxsIE9CRVhfSGFuZGxlSW5wdXQuDQoNCllvdSBoYXZlIHRvIGNhbGwg
T0JFWF9IYW5kbGVJbnB1dCgpIGZvciBzdXJlLiBJdCBkb2VzIHRoZSB3b3JrIGFsc28gZm9yIHRo
ZSBTUk0gY2FzZS4gSSBhbSBhbHNvIHJlZGVzaWduaW5nIHRoZSBzdGF0ZSBtYWNoaW5lIGluIE9w
ZW5PQkVYIHNvIHRoYXQgaW5jb21wbGV0ZSB3cml0ZXMgb24gbm9uLWJsb2NraW5nIHNvY2tldHMg
YXJlIHBvc3NpYmxlLiBUaGlzIGZlYXR1cmUgd2lsbCBiZSBwcm90ZWN0ZWQgYnkgYSBmbGFnIGJl
Y2F1c2UgaXQgY3JlYXRlcyBhIHNtYWxsIHByb2JsZW0gbGlrZSBmb3IgU1JNLg0KSWYgeW91IG5l
ZWQgYSBmdW5jdGlvbiBpbiBPcGVuT0JFWCB0aGF0IHRlbGxzIHlvdSBpZiBpbnB1dC1pbmRlcGVu
ZGVudCB3cml0ZXMgYXJlIG5lZWRlZCwganVzdCB0ZWxsIG1lIG9yIGNyZWF0ZSBvbmUgOi0pDQoN
CkhTDQoNCldoYXQgZG8geW91IG1lYW4gImluY29tcGxldGUgd3JpdGVzIG9uIG5vbi1ibG9ja2lu
ZyBzb2NrZXRzICIgYW5kICIgaW5wdXQtaW5kZXBlbmRlbnQgd3JpdGVzICI/IERvIHlvdSBtZWFu
IHRvIHdyaXRlIGxvdHMgb2YgZGF0YSBvbmUgdGltZSBhbmQgdXNlIEdfSU9fT1VUIHRvIHdha2V1
cCBvYmV4X3dvcms/DQoNClJlZ2FyZHMsDQpOYW1pDQoNCg0KDQotLQ0K

2011-06-22 11:18:18

by Hendrik Sattler

[permalink] [raw]
Subject: Re: SRM support in OBEX

Zitat von Luiz Augusto von Dentz <[email protected]>:

> Hi Nami,
>
> 2011/6/22 Li, Nami <[email protected]>:
>> Hi, Piotr
>> ?I worked on SRM several weeks ago but finally stopped.
>> ?It`s easy to set and check SRM header, as well as set the response
>> mode to OBEX_RSP_MODE_SINGLE. And it is already well supported in
>> obex_work function when the response mode is SRM, client and server
>> can continue send data without remote side response or request. The
>> obex_work callback relationship is:
>> obex_session_start()
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
>> ? ? ? ? ? ? ? ? ? ? ? ?g_io_add_watch_full(io, G_PRIORITY_DEFAULT,
>> ? ? G_IO_IN | G_IO_HUP | G_IO_ERR | G_IO_NVAL, ? ?
>> ?obex_handle_input, obex, obex_handle_destroy);
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
>> obex_handle_input()
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
>> ? ? ? ? ? ? ? ? ? ? ? ?OBEX_HandleInput(obex, 1)
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
>> OBEX_HandleInput()
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
>> ? ? ? ? ? ? ? ? ? ? ? ?obex_work(self, timeout);
>>
>> The problem in SRM is:
>> If remote side doesn`t send any data to local side, then the
>> G_IO_IN condition couldn`t be set. So how obex_work can be called?
>>
>> I haven`t found any good solution for this issue. So if you can
>> spend some time on SRM, I`ll be very happy:)
>
> No top posting in this list, please.
>
> So back to the topic, we probably need to add another watch with
> G_IO_OUT when using SRM so that it wake ups whenever we can write to
> the socket/fd, obviously this should only be active when we are
> sending data (GET) and there is no need to call OBEX_HandleInput.

You have to call OBEX_HandleInput() for sure. It does the work also
for the SRM case. I am also redesigning the state machine in OpenOBEX
so that incomplete writes on non-blocking sockets are possible. This
feature will be protected by a flag because it creates a small problem
like for SRM.
If you need a function in OpenOBEX that tells you if input-independent
writes are needed, just tell me or create one :-)

HS


2011-06-22 07:23:39

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: SRM support in OBEX

Hi Nami,

2011/6/22 Li, Nami <[email protected]>:
> Hi, Piotr
> ?I worked on SRM several weeks ago but finally stopped.
> ?It`s easy to set and check SRM header, as well as set the response mode to OBEX_RSP_MODE_SINGLE. And it is already well supported in obex_work function when the response mode is SRM, client and server can continue send data without remote side response or request. The obex_work callback relationship is:
> obex_session_start()
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
> ? ? ? ? ? ? ? ? ? ? ? ?g_io_add_watch_full(io, G_PRIORITY_DEFAULT, ? ? G_IO_IN | G_IO_HUP | G_IO_ERR | G_IO_NVAL, ? ? ?obex_handle_input, obex, obex_handle_destroy);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
> obex_handle_input()
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
> ? ? ? ? ? ? ? ? ? ? ? ?OBEX_HandleInput(obex, 1)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
> OBEX_HandleInput()
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...
> ? ? ? ? ? ? ? ? ? ? ? ?obex_work(self, timeout);
>
> The problem in SRM is:
> If remote side doesn`t send any data to local side, then the G_IO_IN condition couldn`t be set. So how obex_work can be called?
>
> I haven`t found any good solution for this issue. So if you can spend some time on SRM, I`ll be very happy:)

No top posting in this list, please.

So back to the topic, we probably need to add another watch with
G_IO_OUT when using SRM so that it wake ups whenever we can write to
the socket/fd, obviously this should only be active when we are
sending data (GET) and there is no need to call OBEX_HandleInput.


--
Luiz Augusto von Dentz

2011-06-22 03:55:07

by Li, Nami

[permalink] [raw]
Subject: RE: SRM support in OBEX

SGksIFBpb3RyDQogIEkgd29ya2VkIG9uIFNSTSBzZXZlcmFsIHdlZWtzIGFnbyBidXQgZmluYWxs
eSBzdG9wcGVkLg0KICBJdGBzIGVhc3kgdG8gc2V0IGFuZCBjaGVjayBTUk0gaGVhZGVyLCBhcyB3
ZWxsIGFzIHNldCB0aGUgcmVzcG9uc2UgbW9kZSB0byBPQkVYX1JTUF9NT0RFX1NJTkdMRS4gQW5k
IGl0IGlzIGFscmVhZHkgd2VsbCBzdXBwb3J0ZWQgaW4gb2JleF93b3JrIGZ1bmN0aW9uIHdoZW4g
dGhlIHJlc3BvbnNlIG1vZGUgaXMgU1JNLCBjbGllbnQgYW5kIHNlcnZlciBjYW4gY29udGludWUg
c2VuZCBkYXRhIHdpdGhvdXQgcmVtb3RlIHNpZGUgcmVzcG9uc2Ugb3IgcmVxdWVzdC4gVGhlIG9i
ZXhfd29yayBjYWxsYmFjayByZWxhdGlvbnNoaXAgaXM6DQpvYmV4X3Nlc3Npb25fc3RhcnQoKQ0K
CQkJCQkuLi4NCgkJCWdfaW9fYWRkX3dhdGNoX2Z1bGwoaW8sIEdfUFJJT1JJVFlfREVGQVVMVCwJ
R19JT19JTiB8IEdfSU9fSFVQIHwgR19JT19FUlIgfCBHX0lPX05WQUwsCW9iZXhfaGFuZGxlX2lu
cHV0LCBvYmV4LCBvYmV4X2hhbmRsZV9kZXN0cm95KTsNCgkJCQkJLi4uDQpvYmV4X2hhbmRsZV9p
bnB1dCgpDQoJCQkJCS4uLg0KCQkJT0JFWF9IYW5kbGVJbnB1dChvYmV4LCAxKQ0KCQkJCQkuLi4N
Ck9CRVhfSGFuZGxlSW5wdXQoKQ0KCQkJCQkuLi4NCgkJCW9iZXhfd29yayhzZWxmLCB0aW1lb3V0
KTsNCg0KVGhlIHByb2JsZW0gaW4gU1JNIGlzOg0KSWYgcmVtb3RlIHNpZGUgZG9lc25gdCBzZW5k
IGFueSBkYXRhIHRvIGxvY2FsIHNpZGUsIHRoZW4gdGhlIEdfSU9fSU4gY29uZGl0aW9uIGNvdWxk
bmB0IGJlIHNldC4gU28gaG93IG9iZXhfd29yayBjYW4gYmUgY2FsbGVkPw0KDQpJIGhhdmVuYHQg
Zm91bmQgYW55IGdvb2Qgc29sdXRpb24gZm9yIHRoaXMgaXNzdWUuIFNvIGlmIHlvdSBjYW4gc3Bl
bmQgc29tZSB0aW1lIG9uIFNSTSwgSWBsbCBiZSB2ZXJ5IGhhcHB5OikNCg0KDQpCZXN0IHdpc2hl
cy4NCk5hbWkNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGxpbnV4
LWJsdWV0b290aC1vd25lckB2Z2VyLmtlcm5lbC5vcmcgW21haWx0bzpsaW51eC1ibHVldG9vdGgt
b3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgUGlvdHIgWmeornJlY2tpDQpTZW50
OiAyMDExxOo21MIyMcjVIDIxOjQ0DQpUbzogbGludXgtYmx1ZXRvb3RoQHZnZXIua2VybmVsLm9y
Zw0KU3ViamVjdDogU1JNIHN1cHBvcnQgaW4gT0JFWA0KDQpIaSwNCg0KSXMgYW55Ym9keSB3b3Jr
aW5nIG9uIFNSTSBzdXBwb3J0IGluIG9iZXhkID8gSSBtaWdodCBiZSBhYmxlIHRvIHNwZW5kIHNv
bWUgdGltZSBvbiB0aGlzIGJ1dCB3b3VsZCBsaWtlIHRvIGF2b2lkIGR1cGxpY2F0aW9uIG9mIGVm
Zm9ydCBpZiBpdCdzIGluIHRoZSBwaXBlbGluZS4NCg0KQ2hlZXJzLA0KUGlvdHINCi0tDQpUbyB1
bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGlu
dXgtYmx1ZXRvb3RoIiBpbiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIu
a2VybmVsLm9yZyBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3Jn
L21ham9yZG9tby1pbmZvLmh0bWwNCg==