ICE should export C++ API for TCP/UDP

dragzhb

I think ICE should export C++ API for TCP/UDP

ICE, it's mean Internet Communications Engine, I think it should include TCP/UDP function. because we don't only use ICE to communicate with ICE, but also communicate with traditional socket program, when I use ICE communicate with traditional socket program, I had to find c++ socket API (example ACE) , I don't like c socket API, it's very difficult to use , I think you have C++ API for TCP/UDP in inner, but do not export to constomer to use, could you export C++ API for TCP/UDP like export c++ Thread, it's very usage for user in same environment to usage all functions, thanks

marc

We don't have a generic abstraction for TCP/IP or UDP/IP in Ice. The utility functions we use internally are very specific for Ice, and wouldn't be very useful as a more general abstraction.

dragzhb

Ok, I see. this time ICE has no entirely TCP/UDP API.

Have you plain to export C++ API for TCP/UDP, it's very import in communication program . for 3 reason:

1: use can use thread and Socket API in same environment (in ICE). in communicatio program, thread and socket are base component. and user often use them together.
for example , if you don't export thread API , user use thread must add other vendor API. and it's dfficult to portable in different OS.

2: User don't only use pure ICE in normal environment, but also use traditional TCP/UDP to communicate with other hereditary program.

3. for performance. I have tested ICE's performance (see http://www.zeroc.com/vbulletin/showthread.php?s=&threadid=832), it can't run as fast as pure TCP/UDP. when user enironment is very critical for performance and ICE can't fulfil the requirement, user must use pure TCP/UDP API.

really ,it's import for ICE and customer to add this API!

CBB

Is it recommended anyway to use ICE with other threading libraries? Or is ICE sensible on the way threads get handled? How about using it in conjunction with ACE?

How about using ICE in MFC applications which sometimes are sensible in terms of integrating other threads?

Best,
Christof

marc

The Ice thread abstractions are only a thin layer over the underlying native threads (posix, WIN32, etc.). So you can mix the Ice thread library with native threads, or other thread libraries that also use native threads, in any way you wish.

CBB

Sounds good. Thanks.

lkw

If it's possible I support dragzhb' comment. The reason:

In many telecom projects,those telecom companies most often require us to use TCP/IP directly to communicate with their service applications, but as you see , we of course prefer ICE to TCP/IP . So we should use ICE in internal applications,and write TCP/IP code directly to communicate with telecom's applications?


best,
lkw

marc

There is nothing that prevents you to use TCP/IP directly with Ice. But do we really need to make Ice a kitchen-sink library for all kinds of utilities? There are so many socket abstraction libraries available already. I'm a bit afraid that if we go this route, then Ice might end up like ACE.

Having said this, if this is so important for you, and you are interested in a commercial license agreement with us, then we can add this. Please contact us at [email protected] if you are interested.

lkw

OK,I don't want ICE become a kitchen-sink library for all kinds of utilities:) . And I know ICE grow up on demand^_^.

I just want to say the users used ICE should not want to use other library. If there is socket abstraction layer in ICE,that is so good!


Thanks ZeroC and your ICE!

lkw

xdm

Socket library

I think that is not good idea include external protocols or sockets libary as part of ice beacuase 2 reasons

1) there are a lot of external solutions comercial and gpl that do it yet

2) Ice can comunicate with a external program in many forms tcp/udp , Soap , Http
if ice include all this things complex of Ice grows