1 of 2 people found this helpful
You can use wiced_packet_create_tcp( wiced_tcp_socket_t* socket, uint16_t content_length, wiced_packet_t** packet, uint8_t** data, uint16_t* available_space ) where you can provide the content length to send data in bytes and available space would receive the space available for TCP data in the packet in bytes. For data reception, you can use wiced_packet_get_data (wiced_packet_t * packet, uint16_t offset, uint8_t ** data, uint16_t * fragment_available_data_length, uint16_t * total_available_data_length ) where total_available_data_length would provide the total data length received. For more information, please refer to doc/API.html for description of both APIs.
Thanks for the answer. I will have a connection overhead for establishing a TLS session. Is that something I can measure using the API you suggested, or maybe some other way? That combined with the headers for the protocol and the data itself would constitute tx bytes(that's something I can measure meaningfully)
The above technique cannot be used for measuring data bytes during TLS session. For TLS handshakes, you can check the mbedtls_ssl_context structure for each handshake. The encapsulated parameter in_hslen would provide the current handshake message length and in_msglen would provide the message length in TLS record header.
Hi - I also interested on getting traffic stats like mobileTxBytes and mobileRxBytes in Android. I use HTTP POST and GET with USE_TLS feature from http_client.c
How to measure tx and rx bytes with this API instead from wiced_packet_create_tcp. Please guide...
Hi GauravS_31 - thanks for the inputs.
I checked out the mbedtls_ssl_context structure. It seems that WICED has added some additional fields to mbedtls_ssl_context struct.
So if I understood correctly, for every request sent, I need to look at the out_msglen field to get the actual encrypted data length received. And for response, I need the encrypted data field original_in_msglen?
If I want to check the cumulative bytes sent and received during the handshake, I don't think in_hslen will be sufficient, correct?
I need to count all bytes sent and received during the handshake. To do so, is it correct to count out_msglen and in_msglen after every step in the handshake and get the cumulative value ? I think this can be done in "mbedtls_ssl_handshake_client_step" function in ssl_cli.c by cumulatively counting the in/out bytes after each step : MBEDTLS_SSL_SERVER_HELLO, MBEDTLS_SSL_SERVER_CERTIFICATE all the way till MBEDTLS_SSL_HANDSHAKE_WRAPUP. Can you please let me know if that is the correct way to count the incoming/outgoing bytes during handshake? Should I then also add the handshake length to this cumulative value?