EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Performance on mobile devices

Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.
#8779
Posted: 02/04/2009 02:17:29
by Marcin Budny (Basic support level)
Joined: 02/04/2009
Posts: 3

Hello,

I'm evaluating SecureBlackbox .NET CF 1.0 edition in order to make client certificate authenticated HTTPS connections from old PocketPC 2002 devices. I measured time required for SSL handshake (from call to Get method until DocumentBegin event). This takes up to 14 seconds! Is this a normal time required to make a connection? When I specify TElHTTPSClient.PreferKeepAlive = true, following requests are performed a lot faster, since the connection is reused. But this doesn't solve the problem. The devices are running on 400 MHz Intel XScale processors and are connected to network through PC over RS232 cable. On the other end, there is IIS7 server configured to require client certificates. Loading the certificate itself from PFX file takes around 8 seconds. What can be done to increase the performance?

Note, that I have the trial key removing intended time delays.

The other problem is size of the libraries. Base SecureBlackbox.dll has around 2mb and this is a lot for a mobile device. Can this be worked around somehow?
#8781
Posted: 02/04/2009 04:15:09
by Eugene Mayevski (EldoS Corp.)

Quote
Marcin Budny wrote:
What can be done to increase the performance?


Are you running the application from the IDE? This is a serious slowdown. also does the consequent attempt to connect (within the same application run) work also slowly?

Quote
Marcin Budny wrote:
Base SecureBlackbox.dll has around 2mb and this is a lot for a mobile device. Can this be worked around somehow?


In version 7.0 it will be a bit smaller. Also you can build your own assembly (when you have a license and a source code) and remove some cryptographic algorithms if you don't heed them. Finally, it's a lot comparing to what size? most modern devices come with significant memory amount and support for storage cards. They are not those PocketPC 2002 devices already which had 32 mb of memory...


Sincerely yours
Eugene Mayevski
#8782
Posted: 02/04/2009 04:43:18
by Marcin Budny (Basic support level)
Joined: 02/04/2009
Posts: 3

Quote
Eugene Mayevski wrote:
Are you running the application from the IDE? This is a serious slowdown. also does the consequent attempt to connect (within the same application run) work also slowly?


I'm not running the application from IDE, it's being deployed from cab and run in a way normal user does.
When I have PreferKeepAlive = true, consequent requests are significantly faster. With PreferKeepAlive = false, consequent requests take something like half the time of the first request. But it's still around 8s. Also checked on newer Windows Mobile 5 device with 400MHz processor and first request takes around 5 - 6s.
Also a question: what decides how long the connection stays open with PreferKeepAlive = true? I haven't been able to control it with custom Keep-Alive header.

Quote
They are not those PocketPC 2002 devices already which had 32 mb of memory...

Well unfortunately they are, they have 64mb of shared storage/program memory. Storage card is not a remedy since most devices don't have a lot of RAM memory and loading 2mb dll has a significant impact.
#8783
Posted: 02/04/2009 05:10:23
by Eugene Mayevski (EldoS Corp.)

Quote
Marcin Budny wrote:
When I have PreferKeepAlive = true, consequent requests are significantly faster. With PreferKeepAlive = false, consequent requests take something like half the time of the first request. But it's still around 8s.


PreferKeepAlive of course solves the problem, as it doesn't cause reconnection.

What you can also do is check is the length of the key in certificates (both server-side and client-side. If the key length is 2048 bits or larger, then slow speed is not a surprise - the time needed for handshake grows exponentially as the key length increases.

Quote
Marcin Budny wrote:
Well unfortunately they are, they have 64mb of shared storage/program memory. Storage card is not a remedy since most devices don't have a lot of RAM memory and loading 2mb dll has a significant impact.


If you have a custom specialized application and not a mass market product, customizing the source code and building your own assembly might be an option. But I can't guarantee that you will be able to *significantly* (3-4 times) decrease the size of the assemblies. 50% is possible, I think.


Sincerely yours
Eugene Mayevski
#8786
Posted: 02/04/2009 07:13:49
by Marcin Budny (Basic support level)
Joined: 02/04/2009
Posts: 3

The client certificate had a 1024 bit key and server certificate had a 2048 bit key. I changed server's certificate to 1024 bits and didn't notice any improvement. Maybe it's because I have no certificate validation.

Please answer my question from previous post: what decides how long the connection lasts with PreferKeepAlive = true. In my experience, after a period of inactivity (but Active property returns true), calling the Get method returns last received http status code, but no data is received (no exception is thrown). Instead, the Active property changes to false.
#8788
Posted: 02/04/2009 07:57:47
by Eugene Mayevski (EldoS Corp.)

Hmm, maybe we need to make some speed measurements.

As for keep-alive mode, we don't have any specific timeouts for it. The server closes connection on inactivity. However, keep-alives are designed to be reused during short time (seconds, not even minutes) and not to keep the connection for ages. So it can be that it's our code that incorrectly treats large inactivity period as a lack of response from the server. You can check if it's so by setting SocketTimeout property to 0 (i.e. no timeouts will be used) and seeing if the connection is still closed.


Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.

Reply

Statistics

Topic viewed 1505 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!