Hello. Want to know does ICE serialized objects are being put in HTTP in RPC environment. ? or it goes as serialized buffer ?.
Ice serialize data using Ice encoding into a stream, and this stream is send over the wire using one of the supported transports.
If you want to better understand how the encoding of messages works, you should take a look at the Ice protocol chapter in the Ice Manual.
For a list of the supported transports see https://doc.zeroc.com/ice/3.7/client-server-features/transports
Thanks, however my question was the ICE encoding does not put serialized data into a HTTP protocol ?.
The Ice protocol is an application layer protocol, just like http: see https://en.wikipedia.org/wiki/Internet_protocol_suite#Application_layer
The Ice protocol does not depend on http. The Ice protocol is implemented over various transport protocols, such as TCP (with or without an additional TLS layer), UDP, Bluetooth RFCOMM and WebSocket.
WebSocket (https://en.wikipedia.org/wiki/WebSocket) upgrades an http connection to a binary WebSocket connection. We then use the Ice protocol over this WebSocket connection:
This allows you to use http/WebSocket-aware proxies and firewalls to manage your Ice/WebSocket/TCP connections.
I guess you may see this as sending Ice protocol messages over http, but it's really over WebSocket, not plain http.
Then in terms of serialization, the Ice serialization format is called the "Ice encoding" and is totally independent of http. Ice puts byte sequences encoded using the Ice encoding into Ice protocol messages, and then send these messages over TCP, WebSocket (etc.) connections.
I hope this is clearer now!
Okay. Got it thanks.
My doubt was if i have to send a massive serialized data using ICE encoding using ICE this might be an overhead if it uses some application level protocol. like http https etc...
So in your view ICE has no additional protocol overhead to use and send massive data over wire apart from the ICE serialization. ?
Also would be good if you can share advantages of using ICE over gRPC, Thrift etc... if you have any.
When you send data over Ice, the only overhead compared to writing the same data directly to TCP streams is:
the Ice encoding overhead
The exact overhead depends on the type of data you're sending. For example if you're sending a large sequence of bytes, the Ice encoding will encode the size of this sequence using either 1 or 5 bytes in addition to your bytes. (It's unlikely you can do much better "by hand").
the Ice protocol message overhead
Each Ice message (request, reply) contains header data that consumes some number of bytes. See https://doc.zeroc.com/ice/3.7/the-ice-protocol/protocol-messages. The per-message overhead should be negligible if your payload is very large.
And that's it - Ice is not layered on top of another application protocol.
Ice, gRPC and Thrift are open-source RPC frameworks, and they all provide a binary encoding. For most applications, any of these frameworks should be fast enough, especially compared to solutions using text-based encoding like XML or JSON.
So why choose Ice and not gRPC or Thrift for your project?
Ice, unlike gRPC and Thrift, is a commercial product, with thoroughly tested releases, a comprehensive documentation, numerous demo programs, IDE integrations and more. Making Ice better and helping Ice users is our only focus at ZeroC - Ice is not a side project for us.
On a technical level, a significant difference between Ice and gRPC/Thrift is that Ice is object-oriented while gRPC/Thrift are service-oriented. The gRPC and Thrift team decided that using objects for distributed computing introduces too much complexity (see https://grpc.io/blog/principles/). We disagree - we kept the power of objects while offering an architecture and APIs that are simple to use and understand.
For example with Ice, you can send a proxy (reference to a remote object) as an operation parameter, or receive a proxy as the result from your operation. There is no equivalent with gRPC and Thrift. These Ice proxies then form the basis for other powerful features like bi-directional connections and the Ice Location Service.
And there are other differences that may or may not matter for you, such as the IceGrid and IceStorm services that have no equivalent in gRPC/Thrift.
All the best,