Changes between Version 18 and Version 19 of Symbian_AP_Reconnection


Ignore:
Timestamp:
Mar 3, 2009 10:59:19 AM (10 years ago)
Author:
bennylp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Symbian_AP_Reconnection

    v18 v19  
    101101== Symbian specific issues and solution == #sym 
    102102 
    103 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. 
     103Being 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. 
    104104 
    105105However there are still couple of unsolved issues remaining (probably due to lack of knowledge in our part): 
    106106 - 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 
    107  - 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! 
     107 - 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! 
    108108 
    109109At 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).