Home Help Center

J2Me client and C++ server

albertodsalbertods Member Alberto Della SantinaOrganization: University of Pisa - department of IT EngineeringProject: Mobile remote controller ✭✭
Hi all,
I'm writing a simple application based on the callback example, between a server (in c++) and a client (j2me).

When I run the client, and start the initiateCallback I get this error:
Ice.OperationNotExistException (obviously the server is normally running)
What can be the cause of this problem?



I'm using Ice 3.0.1 for the client and IceEJ 1.1.0 for the embedded version: can they work together or the latter needs the last version of Ice (the 3.1.1) ? I prefer not to upgrade to the last version of Ice because I am going to finish my thesis very soon and everything is set to work with the version of Ice I started to work with.


With my best regards

Thank you in advance



Alberto

Comments

  • beaglesbeagles Member Brent EaglesOrganization: Eagles Technologies IncProject: Asterisk SCF ✭✭✭
    While there should be no problem using IceE for Java with Ice 3.0.1, I highly recommend upgrading if at all possible.

    Your report doesn't include enough information to diagnose the problem. The description of the Ice::OperationNotExistException in the Ice manual might give you a hint as to what has gone wrong.
  • albertodsalbertods Member Alberto Della SantinaOrganization: University of Pisa - department of IT EngineeringProject: Mobile remote controller ✭✭
    Hi Beagles,
    thanks a lot!

    Now I have another issue: do I need a Glacier2 router in order to properly let a real mobile client communicate back and forth with the server?
    Consider the case in which there is no need of a firewall: the server is publicly accessible with a fixed address:port .

    It's not enough to add the server address to the standard "config" file, available with the callback demo, if I want a real mobile client to interact with it. Am I right?


    I would appreciate any help from you.


    With my very best regards



    Alberto
  • beaglesbeagles Member Brent EaglesOrganization: Eagles Technologies IncProject: Asterisk SCF ✭✭✭
    Using Glacier2 to communicate between a mobile application and a server is not a requirement. If a TCP/IP connection can be made between the mobile device and the server, then your Ice MIDlets can communicate directly with the server.

    Since you are experimenting with the callback demo, I expect that you want to be able to invoke callbacks on the client. If your mobile service provider's network does not permit mobile devices to act as servers accepting incoming connections, you will want to use bidirectional connections. See the Ice docs for details.
  • albertodsalbertods Member Alberto Della SantinaOrganization: University of Pisa - department of IT EngineeringProject: Mobile remote controller ✭✭
    thanks a lot Beagles,
    you have been very kind!

    If I don't use Glacier2 for my purposes, how can I modify the "config" file?
    It's not very clear to me how can I put in it the mobile IP address (for the client's endpoint), due to the fact that it changes in every connection (and it's pretty impossible to be found out).

    Callback.Client.CallbackServer=callback:tcp -h SERVER_IP_ADDRESS -p 10000
    Callback.Client.Endpoints=tcp #-h CLIENT_IP_ADDRESS ???
    Callback.Server.Endpoints=tcp -h SERVER_IP_ADDRESS -p 10000
    


    What is the most usual policy for the mobile operators as far as incoming connections (in the mobile) are concerned? Do they tend to disable this feature?



    Thanks in advance


    Alberto
    Instead of using the config file for the client version, I set those parameters directly in the startApp(), but this is irrelevant.
  • beaglesbeagles Member Brent EaglesOrganization: Eagles Technologies IncProject: Asterisk SCF ✭✭✭
    Configuring your MIDlet server is a little tricky. Specifying the host information in a config file is not a good plan since it likely changes every time the mobile's network communications is initialized. However, if you leave it out there is an initialization order issue since IceE cannot always determine the host's address information when it is required. This is due to how the Generic Connection Framework works and is not a problem in non-JME IceE.

    There is a workaround that is used quite successfully in the IceE test suite. Before initializing IceE, the address information is obtained by creating a server socket and querying it for the local address information. Using this information to set the Ice.Default.Host property when initializing the IceE Communicator, the server functionality works as expected. See test/IceE/common/ServerWrapper.java for an example.
Sign In or Register to comment.