Changes between Initial Version and Version 1 of Ticket #1901


Ignore:
Timestamp:
Dec 10, 2015 7:58:33 AM (9 years ago)
Author:
ming
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1901

    • Property Summary changed from Support simultaneous asynchronous read operations for SIP TCP/TLS transport (i.e. support async_cnt > 1) to Fix crash when async_cnt is set to a value greater than one for SIP TLS transport

  • Ticket #1901 – Description

    initial v1  
    1 Currently, there are already options to support this in API``` pjsip_tcp_transport_start()/start2()``` or ```pjsip_tls_transport_start()/start2()``` (and via ``` pjsip_tcp_transport_cfg.async_cnt``` as well). Then ```sip_transport_tcp.c / sip_transport_tls.c``` will issue a call to ```pj_activesock_start_read2()/ pj_ssl_sock_start_read2()```, and should supply the parameter ```readbuf```, which, according to the doc, should be: an array of ```async_cnt``` number of buffers, where each buffer is ```buff_size``` long. 
     1The API ```pjsip_tls_transport_start()/start2()``` accepts parameter ```async_cnt``` which, according to the doc, specifies the number of simultaneous asynchronous ```accept()``` operations to be supported. However, the newly-created incoming secure sockets, which will be created in ```on_accept_complete()``` callback, will also have the same ```async_cnt```. This will result in asynchronous receive operations as well, which is undesirable since ```pj_ssl_sock_start_read2()``` is called only with a single buffer (i.e. ```rdata->pt_info.packet```). 
    22 
    3 However, in the implementation of ```tcp_start_read()/tls_start_read()```, the ```readbuf``` is only hard-coded to an array the size of one, and later, in ```on_data_read()``` there are also assertions to check that the buffer points to a specific, single buffer only (i.e. ```rdata->pt_info.packet```). As a result, this may cause crash such as reported in https://issues.asterisk.org/jira/browse/ASTERISK-25615, with a stack trace like this: 
     3As a result, this may cause crash such as reported in https://issues.asterisk.org/jira/browse/ASTERISK-25615, with a stack trace like this: 
    44{{{ 
    55    frame #2: 0x00007fff8859c62c libssl.0.9.8.dylib`ssl3_read + 156