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
Related
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 :-) !
i'm a newbie to webRTC and their is some stuff that i did not get if it was possible i would like an answer to those question and i quiet think that it will be a good reference to all the other guys over the web .
webRTC server code witch left to be handle by the developer what is it job ? i mean their is a lot of signaling method using websocket and socket.io but what did they send to the server ? .
i see some github sources in may learning path that provide these "id" i'm wondering does the server code provide these id and what is it job ?.
i did not get how i can share video conf in real base scenario .. any concret example explanation ?.
i'm wondering if i can use a combination of signalR and webRTC . is is possible thus signlaR provide real time communication and data delivering and the webRTC provide many many services like video conf .. audio .. data exchange .. etc . and is it a valid server code ? .
1) The server-side differs depending on the method used for signalling. For WebRTC specifically, because any browser that supports WebRTC will also support WebSocket, WebSocket is the likely candidate to be used for the signalling method.
Now, the server-side for WebSocket can be somewhat complex, as you have to first handle the handshake to elevate the protocol to either ws or wss, and after that, you have to handle the encrypting and decrypting of all messages sent over the line via WebSocket. This is not trivial at all, but if you do some searching around SO and the web in general for information about how to code the server-side for WebSocket, you should be able to find what you're looking for.
2) I can't understand what you're asking in this question. Could you please provide an example/link? Thanks.
3) You use WebRTC to establish a peer-to-peer connection between two clients to quickly transfer data back and forth. One benefit of this peer-to-peer connection (and the speed at which you can transfer data) is the ability to establish video connections. Also, you can establish video links between more than two clients at a time, although with too many connections, there can be bandwidth issues.
What specifically do you want to know about how to use this technology for video conferencing?
4) I'm not too familiar with SignalR, but looking at the home page, SignalR is used to push data from the server. WebRTC doesn't use a server at all (once the peer-to-peer connection has been established). By that rationale, WebRTC will likely always provide a better, faster connection than SignalR.
Please clarify some of your questions as noted above, and I will help in any way I can. Thanks.
I can answer number 4...
You can of course use SignalR to do the signaling between clients to get WebRTC running, but SignalR has no built-in functionality for the WebRTC signaling so you are in for a pretty nasty job if you are planning on doing it your self.
Since you are asking about SignalR I am jumping to conclusions here and guess that you are a .NET developer? If so there are .NET libraries out there that already have taken care of the signaling for you. One of them is XSockets.NET.
Just install the sample package from XSockets and you will have a multi video chat up and running in a minute.
Sorry for not answering 1,2 and 3... But I hope that the package from XSockets will solve these quesitons :)
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]
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
I'm developing a multi-player game and I know nothing about how to connect from one client to another via a server. Where do I start? Are there any whizzy open source projects which provide the communication framework into which I can drop my message data or do I have to write a load of complicated multi-threaded sockety code? Does the picture change at all if teh clients are running on phones?
I am language agnostic, although ideally I would have a Flash or Qt front end and a Java server, but that may be being a bit greedy.
I have spent a few hours googling, but the whole topic is new to me and I'm a bit lost. I'd appreciate help of any kind - including how to tag this question.
If latency isn't a huge issue, you could just implement a few web services to do message passing. This would not be a slow as you might think, and is easy to implement across languages. The downside is the client has to poll the server to get updates. so you could be looking at a few hundred ms to get from one client to another.
You can also use the built in flex messaging interface. There are provisions there to allow client to client interactions.
Typically game engines send UDP packets because of latency. The fact is that TCP is just not fast enough and reliability is less of a concern than speed is.
Web services would compound the latency issues inherent in TCP due to additional overhead. Further, they would eat up memory depending on number of expected players. Finally, they have a large amount of payload overhead that you just don't need (xml anyone?).
There are several ways to go about this. One way is centralized messaging (client/server). This means that you would have a java server listening for udp packets from the clients. It would then rebroadcast them to any of the relevant users.
A second way is decentralized (peer to peer). A client registers with the server to state what game / world it's in. From that it gets a list of other clients in that world. The server maintains that list and notifies the other clients of people who join / drop out.
From that point forward clients broadcast udp packets directly to the other users.
If you look for communication framework with high performance try look at ACE C++ framework (it has Java bindings).
Official web-site is: http://www.cs.wustl.edu/~schmidt/ACE-overview.html
You could also look into Flash Media Interactive Server, or if you want a Java implementation, Wowsa or Red5. Those use AMF and provide native functionality for ShareObjects including synching of the ShareObjects among connected clients.
Those aren't peer to peer though (yet, it's coming soon I hear). They use centralized messaging managed by the server.
Good luck