Changes between Version 18 and Version 19 of Symbian_AP_Reconnection

Timestamp:

Mar 3, 2009 10:59:19 AM (15 years ago)

Author:

bennylp

Comment:

--

Symbian_AP_Reconnection

@@ -101 +101 @@
 == Symbian specific issues and solution == #sym
 
-Being a mobile operating system, Symbian has a good support in managing access point connection. In Symbian, the {{{RConnection}}} object is used to manage the connection, and each socket ''handle'' ({{{RSocket}}}) is created in a context of an {{{RConnection}}}. The {{{RConnection.ProgressNotification()}}} method can be used to register an Active Object to be run when the connection status has changed, so the application has good control over the connection.
+Being a mobile operating system, Symbian has good supports in managing access point connection. In Symbian, the {{{RConnection}}} object is used to manage the connection, and each socket ''handle'' ({{{RSocket}}}) is created in a context of an {{{RConnection}}}. The {{{RConnection.ProgressNotification()}}} method can be used to register an Active Object to be run when the connection status has changed, so the application has good control over the connection.
 
 However there are still couple of unsolved issues remaining (probably due to lack of knowledge in our part):
  - when the connection in {{{RConnection}}} is down, it seems that the sockets created with that RConnection will detach themselves from the connection, so even though the RConnection is reconnected, this will not automatically make the sockets recover to a "good" state. If the application tries to make use of the socket, for example, to call {{{!SendTo()}}}, it will cause the socket to pop up the access point selection dialog again
- - more over, if user selects different access point in the dialog, this will put the sockets in somewhat worse state. If the application tries to make use of the socket, for example, to call {{{!SendTo()}}}, it will cause the !TRequestStatus associated with the operation to block for a long time (about one and half minute). And even worse, a second call to {{{!SendTo()}}} will cause the !TRequestStatus to block indefinitely!
+ - more over, if user selects different access point in the dialog, this will put the sockets in somewhat worse state. If the application tries to make use of the socket, for example, to call {{{!SendTo()}}}, it will cause the TRequestStatus associated with the operation to block for a long time (about one and half minute). And even worse, a second call to {{{!SendTo()}}} will cause the TRequestStatus to block indefinitely!
 
 At the moment we are not aware of any solutions for the above issues. Lacking this, we created a workaround in PJLIB to prevent it from accessing any Symbian socket API's when the connection has been down and reconnected. The API is '''{{{pj_symbianos_set_connection_status()}}}''' and it was added in PJSIP version 1.0.2/1.1 (ticket #733 and #732 respectively).