I have a general question here regarding the RSS and XMPP technology. I want to know what exactly makes XMPP a real-time alternative to RSS?
Right now, I'm assuming a one-way message stream (from server to client ONLY).
What I'm confused about is, let's say I program a RSS reader on my client side and make it scan for new feeds for VERY short interval of time. Will that not make my system real-time'ish? Or is there any negative impact on doing that which XMPP resolves (apart from the security features)?
Because there are some systems which uses a combination of the two to form a real-time feeding system (Eg : Superfeedr).
So, if someone can briefly explain why someone would implement XMPP over RSS when designing a real-time notification system, I'd highly appreciate that.
Sorry for the long post, I have recently begun with these two technologies and I'm very curious about their functionalities. I tried looking up on the internet but the answers were either too brief or insufficient.
These are very different things, but complementary.
RSS is just a data format. It does not involve any "latency" by itself. It's just the way it's being consumed which determines if it can be realtime or not.
XMPP is a communication protocol. It's connected and in that regard can be considered as "real-time". RSS itself (or rather Atom), as it's XML, can be transported quite easily over XMPP. That's one of the ways you can make RSS realtime.
And RSS can be realtime if it's served through the PubSubHubbub protocol (is not it, Julien :-) !
Related
I've been doing some research in how to implement a server free, point-to-point video/audio chat (i.e., my own skype without text messaging).
I've been looking for ways to implement it and I had this next ideas:
A multithreaded c++ (cause I know some c++) program getting audio and video (with qt), sending it through 2 different UDP sockets and reading video and audio from 2 other different UDP sockets from the other 'point'. So I'll had to write the UDP server and client multithreaded with a sum of 4 threads: 2 for sending audio and video, other 2 to receive audio and video.
Writing my own protocol to enable video and audio in the same thread, something like parsing half of the packet data size for audio and video buffering, which would leave me with only 2 threads in the application and a lot more 'error prone' code to write.
I've been looking to some real time media protocols, and some of them looked interesting. Maybe study and implement interfaces to this protocols and use them instead of 'creating' my own.
Now, the actual question(s):
Are there some documentation on how to accomplish this? Maybe some 'state of the art' apis/protocols that are being used or well implemented/suited solutions for this problem?
If I choose to implement audio separated from video, is VoIP a possible solution to the audio connection?
Is Qt a good tool for this purpose? I never used Qt before, and for video and audio interfaces I also thought about openframeworks, so I was wondering if anyone has ever used one of this frameworks and if this is the right choice.
I know that my question has no code and that the range of possible answers is wide, but I really need some help here.
Thanks.
First, you should answer on question: How your clients should connect / authorize without server part?
Notes: 1) Skype has servers. 2) A lot of internet users are visiting web throught NAT / Proxy.
Ofc, you can try to implement something for learning proposes, but if you want to create something usefull - try thirdparty solutions that are created by specialists. For example: google libjingle.
You need VOIP library’s :)
There's no need to start from scratch you can use library’s opensource like: opalvoip
I am building a multiplayer game where players are simultaneously asked a question and they have to pick an answer. They have a few seconds to answer and they are asked the next question when the time is out or everyone has answered.
I am planning on using Java (or nodeJS if I feel like learning a new framework) on the server side and JS (jQuery and jQuery Mobile) on the client side. I might build native apps later too so I want to keep the option opened.
My question is: what server communication protocol would you suggest?
I was thinking of regular TCP (HTTP with Ajax) calls since latency is not really the issue but I am ready to review this choice if you suggest otherwise.
Thanks a lot for your help
When using UDP the burden to implement retry and congestion control will fall on you. Therefore, I recommend you stick with the reliable and easy TCP until there is a specific reason to switch. If latency turns out not to be acceptable, which I doubt in your case, you can switch to UDP.
Another thing to remember, if you are creating the game on mobile device and you don't want to lose the players connected over 3G, you will need to make sure you are using standard ports to connect to the server side, otherwise operators will disconnect you.
HTTP Streaming and WebSockets over TCP/IP is the best way to go. Lightstreamer, which leverages HTTP and WebSockets, uses TCP but tries to overcome some of its limits with some smart algorithms for latency reduction (which seems to be crucial for the game you described) and bandwidth optimization. Thus, it can be used with great benefits for any multiplayer games of any complexity (including MMORPGs, for example). At a first glance it seems it can fulfill your requirements, and it could be a good solution if you are also planning to develop native apps in a second step.
Lightstreamer is based on a publish/subscribe model, in which every item is defined by a set of fields whose values can change over time (in order of milliseconds). These could include "general items", subscribed by any users (e.g the game countdown; who is the first responder) and delivered in real-time. This way, the data delivery mechanism underlying your game logic seems quite easy to implement with Lightstreamer.
Have a look at this recent article (Optimizing Multiplayer 3D Game Synchronization Over the Web). You can walk through an online demo of a simple multiplayer 3D world in which Lightstreamer has been integrated for real-time synchronization.
The demo allows you to tweak each parameter of the scenario and simulate any flavor of data delivery, while checking the actual bandwidth consumption. Of course, full source code is available for free on GitHub. You could give it a try. Let me know if you need some help :)
[full disclosure: I work for Lightstreamer]
For quite some time, I've been confused about whether Google chat is server based or is peer to peer like skype or as someone told me is it mix of both server and p2p communication?
Since Google chat history is stored on Google servers (unless you go off the record ), to me it indicates that it should be server based (but ofcourse if needed that's possible with p2p as well).
Now, the person who told me that Google chat is p2p (or that mix option if that makes sense) has quite a lot of experience in networking and I'd generally trust his words, but this time I'm just unable to convince myself that Google chat could be p2p and I'm looking for some citation or something which could help clarify the doubt. Is there someone who knows whether it's server based or p2p?
PS: Sorry if the question doesn't really belong to SO, please help me if another SE site is better place for this question. I just thought that since it's about networking and so it could possibly be fine here.
Google ditched XMPP recently and is now shifting to it's own closed sourced proprietary protocols. Which are still Server Based since google will now record all chat activity and going off record is not an option.
"They phasing out 'chat; with 'hangouts', which reneges on the server-to-server aspects of XMPP. More information on the implications (not directly related to the question) here" - Barney
Previos answer
They use XMPP ( jabber )
Extensible Messaging and Presence Protocol (XMPP)
As answered here
I guess reading Jabber would explain things a bit, it's an open protocol and much of the stuff would be available..
For instance Wikipedia explains a bit
Does anyone have experiance in a lot of these?
I'm not so intrested in the pdf creation part of LCDS.
Just for flex messaging which would give me the best performance? As far as I know LCDS and WebOrb both do real time streaming is that correct?
Basically the question is which gives quickest response and which will allow for most client connected to a single servlet container.
Thanks
Edit 1
This may be clearer what I want. I'm looking to server at least 5000 clients with sub second response times with push messages, I'm trying to figure out which is the most scalable option, I've been quoted several million push messages a day. Obviously we can throw more servers at the problem I'm not convinced thats the most maintainable option.
Its not media streaming I'm looking for, but more event updates. It must work without sticky sessions.
LiveCycleDS & WebOrb are the only ones providing messaging using sockets through RTMP protocol. Note that in this case the clients are not connected to a servlet container, but to a dedicated server included in the product distribution (bypassing the servlet mechanism).
There are more messaging servers on the market, Lightstreamer is one of them. Or Flash media server.
There are many more things to be taken into consideration when choosing a solution however (price, integration with various architectures (like DMZ) and frameworks, paid support, documentation, your relation with the sales representative etc).
My first question so go easy on me :)
I've been developing for years and have written WAY too many apps (mostly web apps) using web services - I'm happy with SOAP/WSDL/etc... I also used to write TCP/IP client-server apps back in the day using good old winsock.
I'm a bit bored and looking for a new project to expand my skills so decided to have a go at doing either a game or some sort of server monitoring and remote control application
I haven't decided which and the answer to this question will hopefully inform my decision.
What I'd like is some advice as to which methods I should be looking to handle the communication.
Let's assume I'm doing thew game for the moment - I want 2-way communication with low latency and the ability to handle as many simultaneous connections as possible.
I've considered web services but it seems like a lot of overhead - especially as I'd need the client to expose one as well.
TCP/IP would do the job but seems like it's a little low-level and I lsoe a lot of the advantages like definitions. Presumably I'd need to formulate a new protocol for the communications etc... I'm also unsure how I'd have one client use multiple channels for concurrent information - eg a chat and updating location information. I could attempt to multiplex this in some way but my initial ideas re: the queuing seem quite messy
.Net remoting - I've not really touched this much at all. Seems to have low overhead and more flexibility than webservices but I don't know enough to evaluate properly.
I'd really appreciate any input you can provide (and a link to a tutorial would be fantastic)
Thanks in advance for your help
EDIT: I've had an answer which points me at a UDP library. Is UDP appropriate for this? For location information/similar which requires no history, I can see how this is advantageous but for a chat, a lost packet could be an issue - or do I manually send back an acknowledgment of receipt? If so, aren't I duplicating TCP/IP functionality for limited advantage?
Apologies if this is an incorrect way to expand on the question - guidance for that appreciated too :)
If you're up to date on .NET 3.5 SP1, then you should use WCF. You say you don't want to use web services, and I assume from that you mean you don't want to use SOAP over HTTP. WCF does a lot more than SOAP over HTTP. In particular, it can do binary over TCP/IP using the same infrastructure. It also has support for peer-to-peer.
Take a look at something like Lidgren and see how that work's. Its written in c# so its able to be used with VB.Net
Lidgren is a socket wrapper, Ive used it in a few small scale multiplayer games, ( mainly by using a header stating packet type. ie first byte represents packet type,
Lidgren