Do remote procedure calls support bi-directional communication?
I. e. is it possible to build a communication mechanism
using "pure" RPC (without any protocols on top of it like XML-RPC, JSON-RPC, Thrift etc.), which
allows two machines to exchange messages in both directions (from machine 1 to machine 2 and vice versa) ?
The old well known RPC (ONC RPC/ SUN RPC) are allow bi-directional connections. Of course at the end you need an implementation which will support that. The is a fork of ti-rpc maintained by LinuxBox https://github.com/mattbenjamin/libtirpc-lbx and a java implementation http://code.google.com/p/nio-jrpc/ with bi-directional rpc support. Both libraries used in NFSv4.1 server/client implementations which require bi-directional RPC.
Related
I am struggling to describe simply what the IP Application layer actually “is”. Some of my terminology may be “not quite right”, so I am happy to be corrected on my terminology as well. Is the application layer a “thing”? Or is it more “conceptual” than that? Is the Application layer on a particular node solely that collection of protocols (such as FTP, POP3, HTTP) that an application needs to adhere to if it is to successfully communicate with another remote application?
Conversely, if I write a program that does not strictly conform to an application protocol (say FTP) then there is nothing in the local “application layer” that will “stop” my attempt to communicate to the remote end using an invalid command? Whereas, if the remote end does conform to the application protocol, then it will reject or ignore my invalid communication attempt?
Or again, I could define my own protocol (not necessary as I guess all scenarios are already covered), and as long as my protocol was “robust and consistent” I could use it to communicate between two remote applications and everything would work? Or, is the Application layer a “thing” separate from the protocols?
The application layer is everything that's inside the application - that is, not within the IP stack (which covers network and transport layers).
If you want your application to communicate with an FTP server it needs to be able to speak FTP in order to work. If you write your own client-server protocol you can do whatever you want.
The network layers are there to make your life easier and to make applications compatible with each other. You can use or not use whatever you seem fit.
“An application needs to communicate with another application on a remote system. Any communication can be thought of as the exchange of messages and data between two partners. There are rules (protocols) that define for an application: what commands are available, the sequence that they can be exchanged between partners and any limitations on the data exchanged. For example: communication with an HTTP server uses commands: GET, POST and PUT (and others), whereas communication with an SMTP (mail) server uses: MAIL, RCPT and DATA, and similarly for other protocols. There are different protocols depending on the nature of the communication e.g. text message transfer, file transfer or video streaming. Any commands that are sent by either partner that do not obey those protocol rules is either: not delivered to, ignored or rejected by the remote application. Nothing prohibits application partners using their “own” communication protocol – for example Skype developed an uses its own protocol. However, there are standard protocols that handle most conceivable communication needs, so developing a new protocol may be unnecessary. If an application uses a “private” protocol its communication will be limited to remote applications that support the same private protocol. In addition to protocols, in a practical, real-world, system there are programming libraries (Programming interfaces) that enable the end-user application to request and participate in this communication. It is the end-user application’s responsibility to interact (send and receive data and parameters) with the (local programming) interface and the comms system’s responsibility to process those requests and deliver the data. In simplistic terms, one data transmission starts at one application and ends at another. However, IP provides other applications, such as DNS, that are used to set up connections, but the operation of these is not visible at the end-user application level. In summary, the collection of protocols and the programming interfaces available and used by an end-user application is the application layer on a system.”
I understand that PKCS#11 is std that defines cryptoki API and KMIP is a protocol that defines message format, but how they are connected or are they even interconnected?
How they both hold their individual significance in cryptography?
PKCS#11 can be considered a protocol of a kind too, it's used to communicate with the hardware devices (to be precise, with the driver modules of those devices). However, it's not suitable for network communications. KMIP is the protocol to communicate with remote key storages and similar services and use the remotely stored keys. This is similar to what PKCS#11 offers locally.
In theory, the protocols partially interlap and are to certain extent interchangeable - Oracle has the PKCS#11 driver/gateway, which talks to the remote KMIP server, and the opposite should also be possible. But, of course, each has its own strengths and weaknesses. Interestingly, both KMIP and PKCS#11 standards are developed by the same people in OASIS.
There's also a paragraph in Wikipedia that answers your question.
I'm working on application running on JBossEAP 6.4 in domain mode. I need to handle multiple (up to 1000) parallel TCP connections from server to different hardware devices.
Connections have to be opened at server side and will be keept up to 90 seconds. All connections uses the same port and protocol, but destination IP adresses are different..
I wonder if JCA adapter is suitable for this use case. Should I create special Activation specification for every single device or use something else than JCA resource adapter?
The question is a bit old, but JCA is a not-that-popular technology so some knowledge about it would be useful despite of the fact you might have been implemented all the things already.
Firstly, JCA is a spec for writing your connector, it's not a connector implementation itself. If you need your application to work with external TCP it's up to you to implement a connector.
Whether JCA is suitable for your particular needs depends solely on the nature of your "different hardware devices". Resource adapters has been designed to be used on per-service basis with possible connections pooling. I.e. all the connections this particular adapter would fire should have quite similar nature and be interchangeable. However, JCA adapters also have sensible advantages outside of this scope, especially in EJB environment. EJB imposes quite harsh restrictions upon your code: no locking, threads spawning, etc. It might be quite difficult to implement TCP I/O without all those things. Here comes JCA and it's threading freedom (MDBs are capable of providing EJB-friendly scope on their activation despite of an underlying thread source).
In conclusion: you should consider using JCA for TCP networking if you're working in EJB environment (or if you're going to do so in observable future). If you're using Spring-powered environment upon Java EE stack it may worth to omit such a complicated technology and stick to some pure Netty networking.
If you choose to proceed with JCA, consider inspecting the JCA SocketConnector I am currently maintaining. It's build upon Netty stack and it could be a good start for you. You can also use it as a source of ideas how to build your own implementation instead.
I wonder if there exist any other technologies used to establish internet connection between applications. Are there any other? I am searching and so far I haven't found anything else described.
There are many abstractions on top of sockets, if you don't want to deal directly with a socket API. UDP, TCP/IP, various RPC protocols, HTTP (which is on top of TCP/IP), etc. Many programming languages have easy methods of doing, say, an HTTP request and getting the resulting document. You can use that to allow applications to talk to each other over the internet without using a socket API.
What are you trying to accomplish?
If you want to skip sockets you basically have to implement your own means of talking to the network card hardware and telling it to communicate with other devices. A socket is just the abstraction chosen for *nix and Windows machines.
I was working on Java Agent Development Framework, which is the language of creating mobile agents. I was wondering that the code that I will write in JADE, will work over HTTP or below the HTTP? As I am opaque to the inside working and execution of JADE I couldn't get the answer directly...Thanks in advance :-)
JADE (or more generally FIPA standard) introduces the concept of platform consisting of one or more containers on which agents live. Each container is made up by a separate JVM. JADE distinguishes between two types of communication, depending on where the talking agents live:
intra-platform communication, when messages are exchanged between agents living on different containers of the same plaform
inter-platform communication, when messages are exchanged between agents living in different platforms
Depending on where the talking agents live, different protocol will be used.
For intra-platform communication one of the following transport protocols will be used:
RMI (default), going directly over TCP/IP
proprietary protocol based on TCP sockets (used in J2ME environment in JADE LEAP platform)
For inter-platform communication one of the following transport protocols will be used:
IIOP (Sun or ORBacus implementation)
HTTP and HTTPS
JMS
Jabber XMPP
Since the question is specific to JADE platform, I strongly encourage you to use JADE mailing list: http://jade.tilab.com/newuser.php