Could it be overkill to use ICE for certain applications?

[mbylstra]

ICE obviously scales well from a single-cpu single-machine single-language application to a multi-machine multi-language application spread out over the internet. However, when "scaling down", does ICE take advantage of the particular architecture? E.g. Does it stop using sockets, and use a more direct mechanism, when it realises that client and server modules reside on the same machine?

What I'm trying to ask is, if you can predict that an application will always remain a single-language, single-cpu, single-machine app, is there any advantage, in terms of performance, in not using ICE? (maybe due to avoiding sockets and conversion to and from SLICE).

The reason I ask, is that the application we are writing is likely to be written purely in Python and mostly distributed over a high speed LAN. However, I like the idea that if we use ICE, and if we decide to write modules in other languages, distribute the application over the Internet, and possibly deploy modules on mobile phones at a later stage, this will require little structural change. On the other hand, using ICE might be considered overkill, especially if we can get better performance using a Python-only solution.

[marc]

No, Ice for Python does always use sockets. The only alternative for single-machine applications would be shared memory. However, these only provide a performance benefit for very large requests, but on the other hand would add a lot more complexity to the Ice core. Therefore we do not use them. Also note Ice is rarely the bottleneck of your application. Have a look at Matthew's article "Optimizing Performance of File Transfers" in issue 20 of our newsletter Connections for some real-world performance data.

[mbylstra]

thanks for the reply

[michi]

In addition, one some platforms, using shared memory is no faster than using TCP/IP over the loopback interface. Ice will of course add its share of overhead to an application. (Dispatching a function call via Ice is slower than a straight language-native function call.) However, unless you have operations that do very little work, the call overhead becomes insignificant compared to the amount of time spent executing application logic. In other words, unless you design the interfaces poorly, such that they are too fine-grained, the presence of Ice won't noticably affect performance.

And, as you say, on the upside, by using Ice, you maintain a clean migration path to distribution and mixed-language environments.

Cheers,

Michi.

[mbylstra]

Could ICE be suitable for applications such as real-time video and audio-streaming? Or would the overhead of translating function calls make this prohibitive? I did notice that Skype is listed as an ICE customer, but is ICE used for the streaming part of the software?

[marc]

Of course! Ice can transmit data faster than your hard disk can read or write, so it's certainly suitable for audio/video. See Matthew's article mentioned above for details. I cannot comment on how Skype is using Ice, but there are several customers who use Ice for audio/video.

[bartley]

Could ICE be suitable for applications such as real-time video and audio-streaming?

We use Ice as the communication layer between robots and software applications used by humans. All communication, including video, between the robots and the client applications is done over Ice. Note that we're not actually streaming video since the robots send individual frames, but it's certainly fast enough to look like video. Our robots have cameras that can serve JPEGs at up to 30 frames/sec, and we usually receive frames in the client apps at over 20 frames/sec (and that's over wireless...it's more like 28 fps if the robot is using wired ethernet). And there's still plenty of bandwidth for other communication (controlling motors/servos, reading sensors, etc.) with the robot.

For more info, see the Telepresence Robot Kit (TeRK).

Chris