SSL Proxy Endpoint and -s

Hi, I've got the following two proxies:
86b86a07-269e-43f5-a5b3-1ae5f58e1efe -t:ssl -h 15.1.1.1 -p 3666 -t 5000
86b86a07-269e-43f5-a5b3-1ae5f58e1efe -o -s:ssl -h 15.1.1.1 -p 3666 -t 5000

Both use an ssl endpoing, while one is one way and has the -s option and the other is just flagged as two way. What is the dfiference in terms of protocol? Are both proxies using an ssl protocol, instead of tcp, and are both encrypted. Or does only the -s proxy use an encrypted channel? I was hoping to call ice_secure(false) on my proxy and have it use a non-ssl protocol. Do I have to create another endpoint to make that happen?

-s means that only a secure endpoint can be used. Otherwise, if you have a secure and a non-secure endpoint, and you do not specify -s, Ice will first try to use the non-secure endpoint, and then the secure endpoint. If -s is specified, Ice will only try the secure endpoint.

If you want secure and non-secure communications, you need two endpoints, one for SSL, and one for regular TCP.

ssl endpoints and bi-directional connections

If I have a server ssl endpoint that a client connects to, using bi-directional sockets, are all callbacks to the client sent via ssl protocol?

Yes, all callbacks will use SSL. It is not possible to have a connection that supports both plain TCP/IP and SSL at the same time. (This is not a limitation of Ice, but applies to SSL connections in general.)

Do you know, off the top of your head, what the performance hit is for using a ssl connection versus a tcp connection (for requests that are largely binary data, like a media stream).

Hi,

Try running the throughput demo (demo/Ice/throughput) on your platform for both TCP and SSL. You'll need to enable the SSL plug-in in the configuration file, and then you can start the client and server with --Ice.Default.Protocol=ssl to use SSL instead of TCP.

Take care,
- Mark

Forgive the elementary question, but I would assume, that by definition, everything sent via an ssl connection is encrypted. Is this right?

Yes, that's correct.

Take care,
- Mark

throughput demo...

I got some Very interesting results. I ran the throughput demo with both tcp and ssl (--Ice.Default.Protocol=ssl and --Ice.Default.Protocol=tcp as command line options). Using tcp, I saw less than 5 MBit/sec consistently. Using ssl, I saw greater than 80 MBit/sec consistenly.

Any ideas as to why this would happen? I would have expected ssl to run slower if anything.

I am running in a 100 baseTx full duplex environment between two Windows XP machines using Ice 2.1.1.

Hi,

This is a known problem in Ice that will be fixed in the next release. If you're willing to compile Ice from source code, you can easily fix this problem by editing src/Ice/TcpTransceiver.cpp and removing the code in the #ifdef WIN32 block starting at line 84.

Take care,
- Mark

Hi Mark, I made the change that you suggested, and am still seeing some interesting results. No matter what, ssl still outperforms tcp (counter-intuitive if you ask me - any ideas why?). Here are the numbers I got:

oneway:
SSL: 76.1905 MBit/s TCP: 47.9386 MBit/s

twoway:
SSL: 69.1802 MBit/s TCP: 55.8971 MBit/s

Hi Gabe,

At the moment I don't have a good explanation for the difference. Before I posted my reply, I verified that I could reproduce your original problem in my environment. Using Ice 2.1.1 on a 100Mbit ethernet, TCP produced about 20MBit/s while SSL produced about 80MBit/s.

After making the source code change I described, TCP now produces the same results as SSL in my environment. This is the expected behavior as the network becomes the bottleneck.

Take care,
- Mark