SSL Proxy Endpoint and -s

in Help Center
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?
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?
0
Comments
If you want secure and non-secure communications, you need two endpoints, one for SSL, and one for regular TCP.
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?
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
Take care,
- Mark
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.
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
oneway:
SSL: 76.1905 MBit/s TCP: 47.9386 MBit/s
twoway:
SSL: 69.1802 MBit/s TCP: 55.8971 MBit/s
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