Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I work on system security and i want to know why we need the RPC programming and what is the differences between RPC and simple socket programming? Both of them have a client and server application,tcp/ip based,IP address,port number ,...
Thanks
RPC is one definition of how to send structured data as a call to the server and get structured data as a response back. You could use any of a wide variety of protocols with the same basic goal, like SOAP or WCF.
Any of those protocols builds on top of TCP/IP, and lets the server and the client communicate using predefined strucures. You could do the same without any of those protocols, but then you would have to set up a new set of custom rules for how the server and client should communicate.
You don't need any of those protocols for communication, and sometimes (in realtime online gaming for example) a custom streamlined protocol is used instead, but for most client-server communication a well known protocol is preferable.
Well, there are a lot of different RPC technologies, so it is hard to say what you are refering to. But generally speaking it is a layer on top of network transports (like UDP and TCP) to marshall parameters and call results. You need it to communicate in a structured way with services. Some commonly used applications and system services use well known RPC mechanisms (like Windows DCOM, NFS mount protocol, Kerberos, SAP RFC).
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
So RESTful APIs are stateless wherein the server does not store any state about the client session on the server side.
And consistent hashing in load balancing is used to associate a client with a server, ie, all requests from a given client will be directed to a given server only (amongst a group of servers) because that server has some data stored in it about that client.
So, if our server uses RESTful APIs then is there no need for consistent hashing while load balancing?
Not necessarily. While RESTful APIs are stateless, your server isn't. Server-side caching doesn't violate the constraints of REST. If a server is able to keep information from a client in its cache, it could make a significant difference if future requests are made to that server instead of to another one which may need to perform more work to retrieve the client's data.
It is very situational, however, so I can't speak to your specific server setup!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I need to launch an application on a remote system from Java. I know the IP address and the location of the executable batch file on the remote system. I am trying to get it done with PSExec but I can't seem to get it to work due to domain issues.
One suggestion was to use REST API instead. I don't see any info on using REST to launch an application. So anyone who can tell me if this is possible?
REST is about resource state manipulation via their representations on the top of stateless communication between client and server. REST is an architectural style and it's protocol independent but, in practice, it's commonly implemented on the top of the HTTP protocol.
Can I use REST APIs to remotely launch an application?
If you can represent your application state as a resource, so you can probably create a REST API to manage it.
In practice, your server can provide a set of URLs to locate the resources and their state can be manipulated via HTTP verbs and representations such as JSON and/or XML.
HTTP headers can be used to exchange some metadata about the request and response while HTTP status code should be used to inform the client regarding the status of the operation.
Keep it stateless by storing all session context in the client.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have to create an application with a permanent connection (I need to send data update from the server) and, in parallel, I need to configure this app. My idea was to use Socket.IO for the connection and use it also for the configuration, with specifics event name.
But someone said that it's better to keep Socket.IO only for sending data from the server and use a REST API to configure the app.
I want to know if using a REST API along with of a Websocket connection is a good practice or not, and if no, why.
You always can provide a REST API along with a WebSocket API for different purposes. It's up to your requirements and it depends on what you want to achieve.
For instance, you can use a WebSocket API to provide real-time notifications while the REST API can be used to manage resources.
There are a few details you should be aware of:
REST is a protocol-independent architectural style frequently implemented over the HTTP protocol and it's meant to be stateless.
In HTTP, the communication is driven by the client: the client requests and the server responds.
WebSocket is a bi-directional, full-duplex and persistent connection protocol, hence it's stateful.
In WebSockets, once the communication is established, both client and server can exchange frames in no particular order.
Just to mention one example of application that provides different APIs: Stack Exchange provides a REST API along with a WebSocket API.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Why can not we send an email using HTTP protocols? An email contains text, so why cant it be send using HTTP?. I searched in every where. But can not understand those documents.So please help me to understand this
The protocols to transfer mails (SMTP, POP, IMAP) are all built on top of TCP and HTTP it built on top of TCP too. At least SMTP and POP are older protocols than HTTP.
Of course you could in theory built some mail transfer protocol on top of HTTP. But this effectively means to rebuilt the functionality we already have on top of TCP so that it now is built on top of HTTP which is on top of TCP again. So this is mostly another layer of complexity without actually gaining a lot.
But I'm pretty sure that they were already several attempts to built SOAP, REST,... API's which care about mail transport. But probably none of this showed to be significantly better than the old protocols we already have, which means that we don't switch the existing infrastructure we have to a new protocol in the foreseeable future. It's not that the existing protocols are that good but to take the effort to replace all of this a new protocol must be significantly better.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm looking at WebRTC and I'm wondering how to implement a solution where the client connects to the PTSN via SIP. It seems like a pretty new technology so I assume that this would not work on IE browsers; is this correct?
Basically, I have a dialpad UI on the page and users who have an SIP account. Can WebRTC enable the end-user to make calls to the PTSN and what does it take to implement such solution?
I'm looking into this as an alternative to Java or Flash based webphones.
Thanks for your suggestions.
WebRTC is indeed new and isn't available on IE or Safari. It is available in beta/alpha on other browsers. IE will probably support it in the future and Safari probably won't for some time.
WebRTC does only the media parts of the negotiation, and as such it means that it does no signaling of its own. SIP can work well with WebRTC, but you will need a JS implementation of SIP (over WebSockets) and then you'll need to unwrap the SIP signaling on the server side and "migrate" it to UDP or TCP.
Asterisk are working on such a server side platform: http://blogs.digium.com/2012/05/23/asterisk-11-webrtc/
More about doing SIP in conjunction with WebRTC can be found here: http://bloggeek.me/html-sip/