Mantis - obex-data-server
Расширенный вид
Номер: Категория: Серьезность: Воспроизводимость: Создан: Изменен:
111 General малая всегда 2008-07-25 14:50 2009-10-21 20:13
Инициатор: pwachend Платформа:  
Ответственный: skirsdeda Операционная система:  
Приоритет: обычный Версия ОС:  
Состояние: закрыт Версия продукта: 0.3.1  
Сборка продукта: Решение: решен  
Трудоемкость: нет      
Примерный срок: нет Решен в версии: 0.4.5  
Суть: 0000111: calling Method org.openobex.Session.Cancel() fails when org.openobex.Session.SendFile() is sending to Sony Ericsson mobiles
Подробности: Hello,
I hope I'm right here.
I'm using rev 1656 of ods from svn.
org.openobex.Session.SendFile() ist started und trys to send data to my Sony Erricson Mobile over an OPP session.
If I don't accept/cancel the connection the Operation never get's an timeout.
Calling the session.Cancel() Method to stop the Sendjob fails with
DBusException: org.freedesktop.DBus.Error.NoReply

In the Additional Information is the output of obex-data-server --no-daemon while the pytonscript is running. The last ** Message: LOCK appearse after calling the Cancel() method of org.openobex.Session

Using an Nokia mobile Phone, I don't even need to call the Cancel() function,
because org.openobex.Error.ConnectionTimeout Error is droped after 30s.
It's seems that the differt implementations of OPP, are interrupting the send processes at differnt points for the user request.

Sorry for my bad english, Regards,
Paul

P.S.: where is the Connect() signal gone?
Шаги по воспроизведению:
Дополнительные сведения: ** Message: obex-data-server 0.4svn
** Message: Using Session bus
** Message: Parsed[0]: opp, Parsed[1]: 6
** Message: Connecting to 00:12:EE:58:72:1C using channel 6
** Message: Connect in progress
** Message: LOCK
** Message: UNLOCK
** Message: LOCK
** Message: UNLOCK
** Message: LOCK
** Message: UNLOCK
** Message: LOCK
** Message: UNLOCK
** Message: LOCK
** Message: UNLOCK
** Message: Connected
** Message: Session created by: :1.36
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response OK, Success
** Message: LOCK
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: event: 0

** (obex-data-server:24366): WARNING **: PROGRESS: 7792
** Message: UNLOCK
** Message: LOCK
Связи
имеет дубль 0000155закрыт skirsdeda ODS does not response the cancel request if the opponent is in a suspended state 
Вложенные файлы:
история
Дата изменения Пользователь Поле Изменение
2008-07-25 14:50 pwachend Новый вопрос
2008-07-25 15:16 pwachend Комментарий добавлен: 0000383
2008-07-25 15:19 skirsdeda Комментарий добавлен: 0000384
2008-10-07 17:06 pwachend Комментарий добавлен: 0000438
2008-10-07 17:22 heston_james Комментарий добавлен: 0000439
2008-10-08 14:18 pwachend Комментарий добавлен: 0000440
2008-10-08 15:05 heston_james Комментарий добавлен: 0000441
2008-10-08 15:19 heston_james Комментарий добавлен: 0000442
2008-10-08 15:21 heston_james Комментарий добавлен: 0000443
2008-10-08 17:59 pwachend Комментарий добавлен: 0000445
2008-10-09 12:12 heston_james Комментарий добавлен: 0000448
2008-10-09 20:39 skirsdeda Комментарий добавлен: 0000451
2008-10-09 20:46 heston_james Комментарий добавлен: 0000452
2008-10-09 20:50 skirsdeda Ответственный => skirsdeda
2008-10-09 20:50 skirsdeda Состояние новый => нужен отклик
2008-10-10 14:12 pwachend Комментарий добавлен: 0000467
2008-10-10 14:24 pwachend Комментарий добавлен: 0000468
2008-10-13 03:12 skirsdeda Состояние нужен отклик => назначен
2008-10-23 23:17 skirsdeda Комментарий добавлен: 0000488
2008-10-24 11:26 pwachend Комментарий добавлен: 0000492
2008-10-24 13:27 pwachend Комментарий добавлен: 0000493
2008-11-29 17:07 skirsdeda Комментарий добавлен: 0000509
2009-01-29 13:10 skirsdeda Связь добавлена имеет дубль 0000155
2009-08-19 01:33 skirsdeda Комментарий добавлен: 0000656
2009-08-19 01:39 skirsdeda Комментарий изменен: 0000656
2009-08-22 04:46 skirsdeda Целевая версия => 0.4.5
2009-08-22 21:09 skirsdeda Комментарий добавлен: 0000657
2009-08-22 21:09 skirsdeda Состояние назначен => отработан
2009-08-22 21:09 skirsdeda Решение открыт => решен
2009-08-22 21:43 skirsdeda Решен в версии => 0.4.5
2009-10-21 20:13 skirsdeda Состояние отработан => закрыт

Комментарии
(0000383)
pwachend   
2008-07-25 15:16   
same behavior in rev 1674 (after bugfix for bug id 51) :-(
(0000384)
skirsdeda   
2008-07-25 15:19   
Thanks for bug report.
No real timeout mechanism is implemented in ods yet, although Cancel should not return DBus timeout. I'll look into that..

Connected signal is gone, because it was causing some race conditions. Now you have to use SessionConnected and SessionConnectError signals from Manager object.
(0000438)
pwachend   
2008-10-07 17:06   
in rev 1999 this problem is still persistent. Same behavior when calling SendFileExt(). Is it possible that these functions set some global lock, so that the Cancle() Function is waiting for its release instead of stopping the send process?

I thing a possibility to cancle an running send process would realy make sence.
(0000439)
heston_james   
2008-10-07 17:22   
Paul,

I think the reason this wasnt fixed by bug 51 is becuase bug 51 was designed to cancel the connection process to the phone.

With Nokia devices when you see the 'recieve data from someone?' message with accept or decline the RFCOMM connection has not yet been established, whereas, with Sony Ericson devices the RFCOMM connection is accepted automaticaly by the device and instead it haults and propts the user for acceptance of the file.

You're quite right though, the documentation states:

        void Cancel()

            Cancels any operation that is in progress.

So, the cancel should cancel the currently in progress file transmition.

Tadas, is this something we should perhaps consider as another one to be completed ready for 0.4?

Cheers,

Heston
(0000440)
pwachend   
2008-10-08 14:18   
Hi Heston,
I did a little closer look on this effect. It seem calling the Cancle() function allways produce an org.freedesktop.DBus.Error.NoReply Error after a longer timeout.
This happens on Sony Erricson and Nokia Phone when calling Cancel() on an connected session object.
The problem seems to have nothing to do with the ods_session_cancel and ods_session_cancel_internal functions in ods-session.c as the Error remains constant after commenting everything but "return True;" out.
Unfortunately my c is very rusty and I have no experience in c dbus programing (I'm connecting to the ods dbus-api over python), but if you can give me a little hint, where this timeout is rooted I'll try my best to fix this.
(0000441)
heston_james   
2008-10-08 15:05   
Hi Paul,

My C is pretty rusty too ;-) I'm a python man myself. Thats is very strange that you get the timeout even when the function isnt doing anything. My guess would be that the method is meant to be returning something which it isnt.

Let me take a little look at the source now and see if I can spot anything.

Paul, if you get chance, join us on the IRC channel.

Heston
(0000442)
heston_james   
2008-10-08 15:19   
Ok, taking a look at this now.

Like I say, my C is a little rusty but it looks as if the Cancel() methods should be asynchronous but its currently not set to return a value.

Whilst we're using "return True;" at the moment I believe this is only for the internal C methods and to have the actual dbus method return properly, and not cause the NoReply error we should be using something like:

    dbus_g_method_return (context);
    return TRUE;

If you look into the other asynchronous methods, such as SendFile() you'll notice that these all call the dbus_g_method_return() to make the method return immediatly.

Unfortunatly I dont have a system available to build ODS on here so I'm not able to patch and test but I would think that is where you need to be looking.

Heston
(0000443)
heston_james   
2008-10-08 15:21   
In addition, in cases where the cancel cannot be performed perhaps we need to use dbus_g_method_return_error (context, error); to return the error which occurred.
(0000445)
pwachend   
2008-10-08 17:59   
ok an kind of ugly hack is something like this:

diff ods-session.c ods-session.c.org:
2023,2024c2023,2024
< session->priv->state = ODS_SESSION_STATE_OPEN;
< g_signal_emit (session, signals[CANCELLED], 0);
---
> } else {
> ODS_SESSION_UNLOCK (session);
2026,2028d2025
<
< ODS_SESSION_UNLOCK (session);
< dbus_g_method_return(context);


this gives the possibility to cancel the send process... but isn't really satisfying.
I'll try to make a better fix when I understand dbus c programming a little bit better.
(0000448)
heston_james   
2008-10-09 12:12   
Paul,

Glad to see you made a little progress on this. Tell me, when you say 'but isn't really satisfying' what do you mean? What more are you trying to achieve other than canceling the send process?

Cheers,

Heston
(0000451)
skirsdeda   
2008-10-09 20:39   
I'm a little confused with this. This is how I understand what you are trying to do:
1) send a file using ods to a phone
2) don't do anything on the phone (neither accept, nor cancel)
3) call ods Session.Cancel function.
Is this correct?

Have in mind that what Cancel function does is interrupt OBEX request by sending CMD_ABORT command. If you don't accept/cancel transfer in remote device then that device is effectively blocking any OBEX data (hence it doesn't receive CMD_ABORT command).
The way how ods should act in such situation would be something like this:
1) When session is started, timeout callback would be added to mainloop
2) In timeout callback (which would be called in predefined time spans) we would check if no data was received from remote device during that time span. If so, session would be disconnected. And this is technically not CANCELLING but rather disconnecting because of a timeout, hence this bug (if I'm understanding it correctly) has nothing to do with Cancel function. It has to do with timeouts which are not yet implemented in ods since this is some tedious programming and it helps only in very uncommon situations.

Cheers,
Tadas
(0000452)
heston_james   
2008-10-09 20:46   
Tadas,

The issue I think Paul has been having here is that with a Sony Erricson and many Samsung handsets, when you call SendFile() we get a TransferStarted() signal emmited but the send process then hangs untill the user accepts the file on thier phone.

Paul wants to be able to call Cancel() on that transmition at this point and disconnect the session, whereas at the moment when trying to call disconnect it wont work because the session is 'busy'.

Does that make sense?

Heston
(0000467)
pwachend   
2008-10-10 14:12   
Right, thats the Problem. With the fix above It's possible to Call the Cancle() Function, but when calling Disconnect() after Cancle() an "org.openobex.Error.Busy: Another operation in progress" Error is dropped.
(0000468)
pwachend   
2008-10-10 14:24   
But I don't understand why this happens:
session->priv->state = ODS_SESSION_STATE_OPEN is set and the DBus Function session.IsBusy() return 0 (False) before Calling Disconnect().

Perhaps I'll find the Problem, when I've a little more time for this at the weekend. But I'd be very thankful, if you give me an other hint, where to search.
(0000488)
skirsdeda   
2008-10-23 23:17   
Could you attach your patch in a unified diff format please.
(0000492)
pwachend   
2008-10-24 11:26   
something like:

--- ods-session.c (revision 1999)
+++ ods-session.c (working copy)
@@ -2020,8 +2020,11 @@
                g_assert (!session->priv->dbus_context);
                session->priv->dbus_context = context;
                /* will return at obex_event{EV_ABORT} */
- } else {
- ODS_SESSION_UNLOCK (session);
+ session->priv->state = ODS_SESSION_STATE_OPEN;
+ g_signal_emit (session, signals[CANCELLED], 0);
        }
+
+ ODS_SESSION_UNLOCK (session);
+ dbus_g_method_return(context);
        return TRUE;
 }


???
(0000493)
pwachend   
2008-10-24 13:27   
or for the newest svn version:

# diff -u ods-session.orginal ods-session.c
--- ods-session.orginal 2008-10-24 11:12:18.000000000 +0200
+++ ods-session.c 2008-10-24 11:17:55.000000000 +0200
@@ -2163,8 +2163,10 @@
                /* set dbus context */
                session->priv->dbus_context = context;
                /* will return at obex_event{EV_ABORT} */
- } else {
- ODS_SESSION_UNLOCK (session);
- }
+ session->priv->state = ODS_SESSION_STATE_OPEN;
+ g_signal_emit (session, signals[CANCELLED], 0);
+ }
+ ODS_SESSION_UNLOCK (session);
+ dbus_g_method_return(context);
        return TRUE;
 }
(0000509)
skirsdeda   
2008-11-29 17:07   
This is now partly fixed in svn. Cancel will send a reply, however the actual cancelling won't happen. This will be completely fixed when I implement timeout mechanism in ods.
(0000656)
skirsdeda   
2009-08-19 01:33   
(изменен: 2009-08-19 01:39)
Implementation ideas for session timeout mechanism:
1. Add timeout at the end of ods_obex_send function
2. timeout (if any) has to be removed at the beginning of obex_event function
3. Add pointer to obex_event function into OdsObexContext struct
4. When timeout happens, it should call obex_event function with phony arguments (ABORT / RSP_TIMEOUT ?) and immediately disconnect underlying transport

server_session timeout mechanism:
when busy (ongoing put request), add timeout when waiting for STREAMAVAIL event. If timeout happens, RSP_TIMEOUT response should be sent to client, underlying transport should be disconnected and server_session finalized. In the beginning of STREAMAVAIL event timeout (if any) has to be removed.
(0000657)
skirsdeda   
2009-08-22 21:09   
session timeouts now implemented in subversion. Needs a lot of testing though.