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
The author of Professional XMPP Programming with JavaScript and jQuery claims that stateless protocols like HTTP are much better to scale, as servers dont have to exchange the state among them, while the author of XMPP The Definitive Guide, claims that XMPP can scale very much better than HTTP.
I'm mind buggled, which of them scales better than the other?
The answer is, as usual, it depends. XMPP may have better scalability properties for some applications, and HTTP for others.
Since no details are provided, I can only provide an answer in the broadest sense possible. The most important factor of scalability, is if you can easily progressively handle more users / transactions / data. Since HTTP is the most popular protocol in the world, and so many people have experience with it, I believe HTTP scales better because there are more resources, knowledge and people available to make that happen.
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 13 hours ago.
Improve this question
I am confused as to what the statelessness of HTTP means in terms of the client.
I get that stateless-ness means the server does not store any state information about the client but does the client still remember the identities of the servers it has interacted with, assuming cookies are not used?
The “remembering” logic you are talking about would have to be added to either the server, or the client, or both. HTTP is just a protocol, not an implementation, and that protocol is stateless because it doesn’t define any remembering logic as part of its specification
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 know my question is broad, but I have no clue where to start my research.
How can one implement VoIP on a server? I am fairly certain it does not use the http/https protocol. If so, what standard/famous protocols one can use? are there any open-source ones? What are good references to start working on that?
Start by looking at the SIP,RTP and RTCP protocols. I believe they form a minimalistic set of required protocols for VoiP
Some relevant open source projects:
http://www.fsf.org/campaigns/priority-projects/priority-projects/highpriorityprojects#Replaceskype
"There are a number of such programs, such as Ekiga, Twinkle, Coccinella, QuteCom, and Jitsi. Unfortunately, these programs only replace some of Skype's functionality, and only in some situations. WebRTC has a mission to enable rich, high quality, Real-Time Communications (RTC) applications to be developed in the browser via simple Javascript APIs and HTML5. Developers should consider helping free software VoIP and video, chat, and multimedia communications projects."
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Let's say somebody invented a new protocol I would put on top of IP. Would two computers from the other ends of the world be able to communicate with it, i.e. would routers forward the frames that aren't standard TCP/UDP/ICMP?
Yes, if it is build on top of IP then it would be routable over the internet. The IP protocol defines the header and payload. The header is used for routing. So you would be able to send custom IP-based protocol data from one computer to another over the internet.
However, both computers will need custom drivers to send, receive and understand the data.
I'm not sure why you'd bother though. If you're sending custom data, you're much better off writing an application level protocol on top of tcp or udp and take advantage of the networking layer built into all computers and operating systems already. It'll be easier to write, maintain, and debug.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I would like to have a database store of user statuses, as they come online/offline/afk. Can ejabberd store status changes to a database?
This feature is not provided as a default in ejabberd, because it does not scale out of the box. This is the reason ejabberd has kept a very low latency and improve the real time nature of XMPP.
It doesn't appear that ejabberd comes with this functionality baked in, but it's possible to achieve something close enough, several different ways - I believe the standard method is to create a component.
Ejabberd is maintaining the presence status of users internally. Its the main feature of the XMPP protocol as the name suggests Presence protocol. To store it on the database and than handle it means delay in request/response and it will not be the real-time operation.
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 read about OpenBTS it's really amazing... but I was wondering if we can use it to build phone-to-phone provider-less network.
Any clues or experiments are really appreciated.
One thing to be aware of is that open BTS is 2G/GSM only - i.e. it does not support 3G/UMTS.
This may or may not be important to you depending on what you would like to achieve.
There does appear to be some discussion on adding this functionality in the future (i.e. building an open node b/RNC effectively) but it will be tricky as the authentication mechanism used in 3G requires the network owning the SIM to provide authentication data for even the most basic communication.
GSM follows a strict client-server model. Mobile phones are intended to be clients.
If you would want to build phones with phone-to-phone capability you would need to implement network functionality in the phone. With this, phone-to-phone (theoretically) could be done in an ad-hoc-network model, with one phone running the network part.
I would suspect that one has to look at impacts on the pyhsical/radio layer as well.
Rather unrealistic, IMHO.
May be of interest:
http://terranet.se/history/
So far this company (TerraNet) seem to be only offering sowftware for creating mesh networks over Wifi (I think Wifi is a big disadvantage due to the battery drain. If only we could use GSM), but they seem to share this idea.