Lab 2 - CORBA
General Information T ask description is on the web Download example and assignment files from https://d3s.mff.cuni.cz/files/teaching/nswi080/labs/sources- 2.zip IDL specification, mapping to C++ http://www.omg.org/spec/CPP/1.3/ http://www.omg.org/spec/CPP11/1.4/ Read the slides T o avoid or solve typical problems ;-) Return to them after you have read the instructions Report issues, ask questions when unclear
The Task Implement a client talking with server we provide, and also reimplement the server by yourself. ⯈ Hello, I am ... ⯇ Hi, your key is ... ⯈ Hello, I am ... and my key is ... ⯇ Hi, wait until I am ready, please ... ⯈ Tell me your status ... ⯇ Here it is ... ⯈ Part of your status is ... ⯇ OK. ⯈ Bye.
Client Implementation IDL is in master.idl Reuse files from the example In, Makefile just update the IDL file Client code goes directly into main() in client.cpp Pass the input parameters (IOR, key) as command-line arguments
Server Implementation Preferably in C++ T alk to us if you wish to implement it in different language Not in Java (half of the tasks is in Java already) Mimic the behaviour of our server reasonably Does not have to respond with exactly the same values Use common sense
Notes Print what the client does to standard output cout << "Connected, peer " << peer << ", key " << key << endl; Use sleep(1) when waiting for idle Do not overload the server
Common mistakes It's C++, so be careful about: undefined behavior synchronization memory allocation and deallocation differences between similar types C++11 makes it easier Read the corresponding C++ language mapping specification
Undefined behavior It is an error to invoke undefined behavior even if your program works... but it may fail on a different platform, compiler version, etc. When reading from an union type, check the discriminant _d before calling the accessor in the C++03 mapping, calling the wrong accessor is undefined behavior in the C++11 mapping, it throws an exception
Synchronization Server code can be executed in parallel access to shared data must be synchronized #include <mutex> std::mutex g_mutex; std::lock_guard<std::mutex> lock(g_i_mutex);
Memory allocation 1/4 Avoid memory leaks free allocated memory release references of reference-counted objects don't forget that exceptions may be thrown it's best to rely on smart pointers CORBA may deallocate (in)out parameter e.g. inout strings pass as copies in C++03 may need CORBA::string_dup(str) Do not confuse a servant reference with the corresponding CORBA object references
Memory allocations 2/4 CORBA object references use reference counting C++03: A_var automatically releases the reference C++11: IDL::traits<A>::ref_type behaves like std::shared_ptr Use the correct allocation functions strings in C++03: CORBA::string_alloc , CORBA::string_free do not mix with malloc / free or new / delete servants in C++03: allocate by new , released by reference counting servants in C++11: allocate by CORBA::make_reference , released by reference counting
Memory allocation 3/4 On the server, release the servant implementing instance_i when the client calls disconnect for simplicity, you may ignore the possibility that the client forgets to call disconnect a proper solution would use a time-out, etc. We allow that the server does not have a "clean exit" path (must be killed by Ctrl+C, like the example server) then it is not possible to properly free all memory at least make sure that: if the client calls disconnect , then all memory allocated for the instance is released there are no other leaks on any remote method invocations
Memory allocation 4/4 Finding memory leaks try valgrind --leak-check=full ./client should not report any errors on your client
Use the correct CORBA types long in IDL is not long in C++ maps to CORBA::Long in C++03 maps to int32_t in C++11
Common Problems MARSHAL exception when calling connect() (or ping() ) for the first time Is IOR string really correct? Class (e.g. String_out ) cannot be instantiated because it has private constructor Deriving correct mapping of IDL solely from function signatures in master.h might be misleading! Parameter types are for omniORB implementation or for server, not for client Correct client types are automatically type-casted
Submission In C++ and omniORB or TAO or C++11 and TAOX11 Server might be in different language (talk to us first) By e-mail (deadline is on the web) The submission shall be easy to start Do not send any generated files (but send the build script) Brief README never hurts Especially if your server behaves slightly differently
Recommend
More recommend
