This content has been marked as final. Show 11 replies
You're using some rather confusing language which makes answering your question a little hard.
DSMCC was originally developed using CORBA to send messages over a conventional point to point, bi-directional TCP connection.
The DSMCC object carousel was developed later and (I'm told) basically involves transmitting a serialized form of the CORBA messages originally sent via TCP.
In theory the org.dvb.dsmcc API can address files via both the carousel / serialized form and the original form. The **same** APIs could use both mechanisms depending on things like the NSAP address passed to ServiceDomain.attach.
In practice, the use of the API via CORBA / TCP is optional and isn't implemented. Hence the practical answer is that no APIs use the RPC mechanism or IDL.
There are many ways of addressing the return channel without using DSMCC.
java.net supports TCP sockets, UDP packets and may support HTTP.
javax.net.ssl supports secure connections.
If it doesn't support HTTP, there are implementations of HTTP in Java.
You can use HTTP directly or put use a small XML parser to put SOAP on top of it.
The most widely used small XML parser is nanoXML.
What do you want to use the return channel for?
once again thanx a lot for the valuable info......
we are planning to use it for applications like interactive gaming to send the controls back to the server.
now i have a doubt from DSM-CC spec(ISO 13818-6),in the page 110 they have shown 4-Application and Service Interfaces.
can u explain "Model C" a bit in detail with some real time example.
we are using java.net .
i am not sure about interactive games using DSM-CC.what i am thinking is that the application downloaded(through object carousel) may specify the return path via DSM-CC....is it correct?? if not then what decides the return path either via DSM-CC or HTTP/UDP??
it will be more useful for me if you can explain about this.
thanks in advance for the nice reply i am going to get.
(Disclaimer: this is typed form memory and I haven't had time to check it properly. I may be wrong about this!)
The DSM-CC specification can be very confusing when you're talking about broadcast networks, and it's best to read it together with the DVB data broadcasting spec to get a better idea of what can be used.
The main DSM-CC specification assumes a two-way network, which you can't assume in a broadcast network. For this reason. most broadcast systems do not support the use of DSM-CC for two-way traffic. In a two-way network, DSM-CC acts much closer to a remote procedure call mechanism, which is what the models you refer to are discussing. In a broadcast network, the objects are actually downloaded to the client and are manipulated locally, so they can't be used for communication like this.
In the case of an MHP/OCAP box, you should use java.net for all communication with other machines. This will always be carried out via an IP connection over the return channel rather than using DSM-CC. So the short answer is, DSM-CC will never be used for return path communication in a JavaTV environment.
DSM-CC can be used for return path communication because DSM-CC spec says about User-User interface where a client can operate on the remote server objects.DSMCC spec is transport independent and for return channel usage DVB specifies the use of IIOP which is a version of GIOP. In IIOP the messages are carried over TCP/IP and hence java.net package is used for carrying IIOP.
we are using java.net .Good.
i am not sure about interactive games usingSupport for the return path via DSM-CC is optional.
DSM-CC.what i am thinking is that the application
downloaded(through object carousel) may specify the
return path via DSM-CC....is it correct?? if not then
what decides the return path either via DSM-CC or
As far as I know, nobody has implemented this option.
I **strongly** recommend you forget all ideas of using
DSM-CC with the return path.
To use the return path, all your application has to do is create
it will be more useful for me if you can explain
thanks in advance for the nice reply i am going to
We can think of two kinds of interaction for an application.
1) An application that resides on the client may want to communicate with the server. (For eg., a game application in the client may wish to upload the score onto the gaming server)
2) The application itself can reside on a remote server. The client while running the aplication is in fact invoking methods on the objets residing in the server.
Now my understanding is that, for the first scenario, the application just needs to open a socket and send the score to the server. ( using java.net). This is the return channel that we have been talking about in this thread so far.
DSM CC API also supports the second scenario, of accessing remote objects via the RPC mechanism. DSMCC spec specifies a SII ( Service interoperability Interface) with a one to one correpondence with the APplication portability Interface that is visible to the application.
The doubt i have is while implementing MHP/OCAP, do we need to support the RPC mechanism? Or are we definite that the applications that will ever run on an MHP/OCAP terminal will always be broadcast using broadcast network and hence is available locally?
Hope the query is clear and hoping to see a response!