0000111: calling Method org.openobex.Session.Cancel() fails when org.openobex.Session.SendFile() is sending to Sony Ericsson mobiles

(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.

Комментарии
(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.

история
Дата изменения	Пользователь	Поле	Изменение
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	Состояние	отработан => закрыт