I am eager to know the working flow of the XMPP, SIP and Web RTC.
I have researched a lot about this, but frankly saying couldn't get a proper idea of their working flow.
I want to know which one is best and why? Are they all using the same kind of architecture or workflow?
Please help me to get the clear picture of it.
On a humble note you are trying to cover many oceans in one stroke. I would like to help in simplest possible manner :
XMPP, SIP and webRTC are all related to IP telephony and communications world. Communication world is majorly categorized in two parts : 1.Signaling 2.Media
XMPP and SIP are categorized as signaling protocols ie the type of protocols which controls and govern media related features while webRTC is one type of media protocol which actually exchanges communication data securely,adaptively and seamlessly based on the parameters exchanged during any signaling protocol.
Depending upon the features like simple call,call forwarding,call hold, SIP trunking etc call flow differs but in general difference remain the same. For more details kindly refer the RFCs of all three protocols.
Related
Could you suggest a portable library for creating realtime bi-directional sockets that do not rely on the HTTP/S or any other plain text protocol? I'd like to send data up and down in the smallest chunks possible.
The protocol must support TLS
Everything to do with WebSockets is off the list.
Though portable, I'm specifically looking for something that will work in Python and Java (Android)
Thanks.
If you google RTP you might find some interesting resources. Among other things, this is what ip-telephony likes to use.
I read that Rest is an architectural style and is not a protocol. I would appreciate if someone can elaborate on this.
Thanks
A protocol usually describes the exact messages (or parts thereof) the two (or more) peers have to exchange. Specifying also the choreography how these messages are exchanged and what they mean.
An architectural style (like REST) does not describe messages at all, but specifies requirements (architectural constraints) that the messages, choreography or parts of the system have to fulfill.
So while a protocol might say: "use JSON in the following format to request a quote". An architectural style just says: "clients can contact servers, but not the other way". It's a completely different level.
Here is how they are related: An architectural style is like a template for a specific architecture. A specific architecture in turn defines the protocols between components.
I read that Rest is an architectural style and is not a protocol. I would appreciate if someone can elaborate on this.
From Fielding's thesis
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
The overview of the architectural constraints that make up the REST architectural style are described in section 5.1
It may also help to review Fielding's presentation REST in AEM, where he calls out specific misunderstandings of what REST is.
In contrast, if you look at the introduction in RFC 7230, you'll see it opens with
The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible interaction with network-based hypertext information systems.
You might look to Jan Newmarch's Network Programming in Go, which includes a chapter on application-level protocols.
A protocol defines what type of conversation can take place between two components of a distributed application, by specifying messages, data types, encoding formats and so on.
REST, you'll note, doesn't specify any of these -- it only constrains the choices you can make.
A good analogy is to think of a protocol as how to write a message and REST as how a machine deals with a message it receives.
Think of a protocol as defining how data between two endpoints is organized. There are several different protocols like HTTP, TCP, IP and ARP. What all of them have in common is that they represent a standard for how to define data in a universal way such that any machine running a program that can interpret data through those protocols will interpret a signal the correctly and precisely. In each case, every time you send out a request your sending out binary to a network (which can include the internet). The binary representations are configured in such a way that they are messages configured in a protocol such as HTTP depending on which layer of networking layer your focusing on (HTTP is in the application layer and you can read more here: OSI model).
REST, on the other hand, handles data sent to endpoints based only after its message has been interpreted. In other words, a message is received, that message is translated into commands, those commands are executed, a response is generated and that response message is translated using a protocol (usually HTTP in the application layer) which is then sent back as a response.
When point A sends a request to a REST API architecture at point B it first translates that data into a standardized protocol (e.g. HTTP at the application layer and others as needed) then sends that message through a network until it reaches point B. When point B receives that data it translates that data and passes it into its REST API which interprets the data as commands and runs their specific functions. After the functions rub by the API are complete, it encodes data again using a protocol and sends a response back to point A.
You can think of it like this. The protocol creates the message so it can be sent and understood. REST is responsible for ensuring the server does operations expected of it not defining the standard for how the data is to be organized so it can be recognized by all possible end points.
There are some good references here:
Communications Protocol
Representational state transfer
It's complicated and takes a while to grasp. There's a lot more to it than what I've shown here but hopefully it serves as a good starting point for you.
First off, I intend no hostility nor neglegence, just want to know people's thoughts. I am looking into bi-directional communication between client and server; client being a web application. At this point I have a few options: MS-proprietary duplex binding, from what I hear unreliable and unnatural: comet, and web sockets (for supported browsers).
I know this question has been asked in other ways here, but I have a more specific question to the approach. Considering web sockets are client-side, the client code sits in JavaScript. Is it really the intention to build a large chunk of an application directly in JavaScript? Why didn't W3C do this in web services? Wouldn't it be easier if we were to be able to use SOAP to provide a contract and define events along with the existing messaging involved? Just feels like the short end of the stick so far.
Why not make it simple and take advantage of JS dynamic nature and leave the bulk of code where it belongs....on the server?
Instead of
mysocket.send("AFunction|withparameters|segmented");
we could say
myServerObject.AFunction("that", "makessense");
and instead of
...
mysocket.onmessage = function() { alert("yay! an ambiguous message"); }
...
we could say
...
myServerObject.MeaningfulEvent = function(realData) { alert("Since I have realistic data...."); alert("Hello " + realData.FullName); }
...
HTML 5 took forever to take hold....did we waste a large amount of effort in the wrong direction? Thoughts?
Sounds to me like you've not yet fully grasped the concepts around Websockets. For example you say:
Considering web sockets are client-side
This is not the case, sockets have 2 sides, you could think of these as a Server and a Client, however once the connection is established the distinction blurs - you could then also think of the client and the server as "peers" - each can write or read in to the pipe that connects them (the socket connection) at any time. I suspect you'd benefit from learning a little more about HTTP works on top of TCP - WebSockets is similar / analogous to HTTP in this way.
Regarding SOAP / WSDL, from the point of view of a conversation surrounding TCP / WebSocket / HTTP you can think of all SOAP / WSDL conversations as being identical to HTTP (i.e. normal web page traffic).
Finally, remember the stacked nature of network programming, for instance SOAP/WSDL looks like this:
SOAP/WSDL
--------- (sits atop)
HTTP
--------- (sits atop)
TCP
And WebSockets look like this
WebSocket
--------- (sits atop)
TCP
HTH.
JavaScript allows clients to communicate via HTTP with XMLHttpRequest. WebSockets extends this functionality to allow JavaScript to make arbitrary network I/O (not just HTTP), which is a logical extension and allows all sorts of applications that need to use TCP traffic (but might not be using the HTTP protocol) to be ported to JavaScript. I think it is rather logical that, as applications continue to move to the cloud, that HTML and JavaScript support everything that is available on the desktop.
While a server can do non-HTTP network I/O on behalf of a JavaScript client and make that communication available over HTTP, this is not always the most appropriate or efficient thing to do. For example, it would not make sense to add an additional round-trip cost when attempting to make an online SSH terminal. WebSockets makes it possible for JavaScript to talk directly to the SSH server.
As for the syntax, part of it is based on XMLHttpRequest. As has been pointed out in the other posting, WebSockets is a fairly low-level API that can be wrapped in a more understandable one. It is more important that WebSockets support all the necessary applications than that it have the most elegant syntax (sometimes focusing on the syntax can lead to more restrictive functionality). Library authors can always make this very general API more manageable to other application developers.
As you noted WebSockets has low overhead. The overhead is similar to normal TCP sockets: just two bytes more per frame compared to hundreds for AJAX/Comet.
Why low-level instead of some sort of built-in RPC functionality? Some thoughts:
It's not that hard to take an existing RPC protocol and layer it on a low-level socket protocol. You can't go the opposite direction and build a low-level connection if the RPC overhead is assumed.
WebSockets support is fairly trivial to add to multiple languages on the server side. The payload is just a UTF-8 string and pretty much every language has built-in efficient support for that. An RPC mechanism not so much. How do you handle data type conversions between Javascript and the target language? Do you need to add type hinting on the Javascript side? What about variable length arguments and/or argument lists? Do you build these mechanisms if the language doesn't have a good answer? Etc.
Which RPC mechanism would it be modeled after? Would you choose an existing one (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) or an entirely new one?
Once client support is fairly universal, then many services that have normal TCP socket will add WebSockets support (because it's fairly trivial to add). The same is not true if WebSockets was RPC based. Some existing services might add an RPC layer, but for the most part WebSockets services would be created from scratch.
For my noVNC project (VNC client using just Javascript, Canvas, WebSockets) the low-overhead nature of WebSockets is critical for achieving reasonable performance. Until VNC servers include WebSockets support, noVNC includes wsproxy which is a generic WebSockets to TCP socket proxy.
If you are thinking about implementing an interactive web application and you haven't decided on server-side language, then I suggest looking at Socket.IO which is a library for node (server-side Javascript using Google's V8 engine).
In addition to all the advantages of node (same language on both sides, very efficient, power libraries, etc), Socket.IO gives you several things:
Provides both client and server framework library for handling connections.
Detects the best transport supported by both client and server. Transports include (from best to worst): native WebSockets, WebSockets using flash emulation, various AJAX models.
Consistent interface no matter what transport is used.
Automatic encode/decode of Javascript datatypes.
It wouldn't be that hard to create a RPC mechanism on top of Socket.IO since both side are the same language with the same native types.
WebSocket makes Comet and all other HTTP push type techniques legible by allowing requests to originate from the server. It is kind of a sandboxed socket and gives us limited functionality.
However, the API is general enough for framework and library authors to improve on the interface in whichever way they desire. For example, you could write some RPC or RMI styled service on top of WebSockets that allows sending objects over the wire. Now internally they are being serialized in some unknown format, but the service user doesn't need to know and doesn't care.
So thinking from a spec authors POV, going from
mysocket.send("AFunction|withparameters|segmented");
to
myServerObject.AFunction("that", "makessense");
is comparatively easy and requires writing a small wrapper around WebSockets so that serialization and deserialization happens opaquely to the application. But going in the reverse direction means the spec authors need to make a much more complex API which makes for a weaker foundation for writing code on top of it.
I ran into the same problem where I needed to do something like call('AFunction', 'foo', 'bar') rather than serialize/de-serialize every interaction. My preference was also to leave the bulk of code on the server and just use the Javascript to handle the view. WebSockets were a better fit because of its natural support for bi-directional communication. To simplify my app development, I build a layer on top of WebSockets to make remote method calls (like RPC).
I have published the RMI/RPC library at http://sourceforge.net/projects/rmiwebsocket/. Once the communication is setup between the web-page and the servlet, you can execute calls in either direction. The server uses reflection to call the appropriate method in the server-side object and client uses Javascript's 'call' method to call the appropriate function in the client-side object. The library uses Jackson to take care of the serialization/deserialization of various Java types to/from JSON.
WebSocket JSR was negotiated by a number of parties (Oracle, Apache, Eclipse, etc) all with very different agendas. It's just as well they stopped at message transport level and left higher level constructs out. If what you need is a Java to JavaScript RMI, check out the FERMI Framework.
I was wondering if it is possible to have a RESTful web service and a bidirectional communication with the clients and server.
In my case the state on the server can change, so the server should send a message to the clients to update themself. Perhaps that's totally against the RESTful idea.
Can I AJAX help me with this issue?
Thanks!
Not really possible under the standard http paradigm, but check out Comet for a possible workaround on that problem and there is alway polling.
The functionality you are after is treated by the concept of web sockets, but they are not mainstream yet.
To keep your solution RESTful you can have the clients poll your service. You can optimize any number of ways, like implementing a special method that lets clients query for changes given a timestamp, then the client just keeps track of when it last checked.
You should take a look at BOSH. BOSH is similar to Comet, but more specific, and I think, there are more reliable implementations.
Though, you will have problems serving multiple users at the same time if you want to use a standard REST service. You should think of some other implementation using nonblocking IO.
There are probably more questions about bosh. Of course, there are websockets now too, but if you need to serve old Browsers, you cannot rely on them.
Looking for ideas on how to implement a kiosk style/full screen client that will display messages sent to it, in realtime or push based. Basically, think a 911 dispatch center call board. I was thinking a xmpp bot to display, and making a simple xmpp client that can only send messages to the bot.
This is for a very small emergency disaster agencies war room, and only needs to be able to display simple messages entered in from one of the computers in the building. Is XMPP a good solution for this?
An IM protocol like XMPP is an acceptable solution for this.
XMPP seems to fit the bill, it is mature and has many clients that support it so it would not be necessary to write a client, just set up a regular IM client to send to the "buddy" that is the big board.
Are you looking at the problem backwards? Describe what you want to do a little more THEN seek advice on protocols. It smells like you might be designing around a protocol rather than designing around your requirements.
This should be as simple as a single HTML page, running full screen, using Strophe.js and an XMPP account. Strophe is an easy-to-use XMPP library in Javascript.
Something like the basic.{html,js} example here should be pretty much what you want:
http://code.stanziq.com/cgit/strophe/strophejs/tree/
Sounds like a simple pubsub setup (XMPP will work for this) where the clients are all publishers and the War room is the only subscriber. This eliminates the need for rosters so it keeps the intial configuration pretty simple.
I don't know what language you prefer to use, but it would be rather simple in Smack using the pubsub API and any XMPP server you prefer that supports the pubsub extension. (You will need to build Smack from source though as that particular API is new and not in the release version yet.)