How to build a simple 2-player game, communicating over the internet, with no custom code on any server? - instant-messaging

How can I build a simple 2-player game, that communicates over the internet?
I need to solve the problems of:
lookup or rendezvous - two players want to find each other.
ongoing communications. Either player can initiate an action that requires delivering information to the other side, in a reasonbly quick timeframe (IM-type latency, not email-type latency).
In this regard, I suppose it is equivalent to a 2-way chat, where people want to be able to find each other, and then also, once paired up, intercommunicate.
Further requirements:
for now, assume the endpoints are Windows OS, relatively recent.
assume neither endpoint machine is directly accessible from the internet. Assume they are client machines, hidden behind firewalls that block incoming requests. The machines can make outbound requests. (say, over HTTP, but TCP is also fine)
communication should be private. For simplicity, let's say there's a shared secret already in place, and the endpoints are able to do AES. I guess what I mean by this is, any intermediary should not need to decrypt the message packets. The decryption will happen only at the endpoints.
all custom code should run only on the client PCs.
Assume there is no server in the internet that is under my control.
I'm happy to use third-party servers to facilitate intercommunication, like an IM server or something, as long as it's free, and I am not required to install custom code on it.
What APIs are available to facilitate this design?
Can I do this with IM APIs? WCF? Are there WCF Channels for Windows Messenger?
What protocols? HTTP? I have this tagged as "peer-to-peer" but I mean that virtually; there's no hard requirement for a formal p2p protocol.
What message formats would you use?
EDIT
To clarify the requirements around servers, what I want is NO SERVER UNDER MY CONTROL. And NONE OF MY CUSTOM CODE ON ANY SERVER. That is not the same as "No server".
Think of it this way: I can send an email over SMTP, using custom code that I write on the sending and receiving side. My custom code can connect via a free SMTP server intermediary. This would require no installation of code on the SMTP server. This is something like what I want, but SMTP is not acceptable, because of the latency.
EDIT2
I also found this: library for Instant Messaging, like libpurple, but written in C#
ANSWER
I can do what I want, using libraries for IM frameworks. One simple way to do it using Windows Live Messenger is to use the Messenger Activity SDK. This proves the concept, but is not really a general solution. But, similar things can be accomplished with the IM libraries for various messenger systems, like libpurple, or using libs for IRC channels. In all these cases, the IM servers act as the firewall-penetrating communications infrastructure.

IM is the wrong tool. Instead, use an IRC chat room.
With an IRC chat room, your clients "log in" to the chat room, and that is used for your "presence". Anyone in the chat room is "available" to play the game.
Once that is done, the game instance communicate with each other through the chat room. They can use the global channel, or simply private IRC channels for game traffic.
The issues to solve:
First, all game state is shared on the clients. Many games have done this (RTS's like Age of Empires, RPGs like Diablo). But client states are susceptible to hacking and cheating. That's just a plain truth. If the game is popular, it WILL be hacked.
Ping traffic. Basically the flow is you log in to the room, your client is in "available to play" mode. Then it pings EVERYONE ELSE to see if THEY are available to play. This will happen with every client "sign in" to the chat room. You can then use the public room for broadcast events "Frank is ready for a new game", "Frank started a game with Joe", etc. That can help keeps games in sync and not chatty, but when a client connects to the chat room, it's going to go "Hi All, it's Bob, what are you all doing". So you need to manage that.
Traffic volume. IRC rooms can handle a lot of traffic, but not a LOT of traffic. Most are designed to prevent "spamming", "flooding", etc. So you may well be rate limited on you game play. Not a problem for "Checkers", more so for "World of Warcraft" during a 40 man Raid. That's a game design issue.
Terms of service. The IRC provider may well say "Uh no, you can't do that with our service". I haven't looked in to it, so I don't know, but could be an issue.
Other than that, IRC is a pretty good fit. Lots of IRC bot code floating around on the net, I've never used any of it.

Every two-player game must have some type of server environment by the basic need of having to communicate between two clients/players at the very least. Keep in mind, each of the clients/players can also act as its own server to communicate with other linked clients. But the need to keep tabs on all clients/players at any given time and the need to facilitate searching of other clients/players inherently requires some type of server environment to begin with.

libpurple along with otr can give you the privacy-over-IM such an application would need.

You could setup a message board on one of the free message board servers so that players can find each other. You'll probably want to encourage them to use private messages to exchange IP addresses. Then, use a protocol that connects using IP addresses. Good luck with that. Firewalls make it a pain.
Then, of course, one machine of the pair would need to act as server, the other as client. Your software must contain both sets of code. I've written such a game and can tell you that the communication code gets a little confusing.
I can tell you right now that you'd be much happier in life if you wrote a web service to facilitate communication. But, then, you'd need a server for that.
Good luck. You're going to need it.
OR, you could just write a game for an IM client, like Microsoft Messenger. I've seen games for that one, so I know it can be done.

As somebody has said, it may not yet possible to do so if you don't have any mediated server between 2 players. As you're happy to use third party server, I suggest that you build your system using Google App Engine + XMPP over HTTP. It works nicely over internet and behind firewall. And yet it's free (as long as your system doesn't grow out of GAE quota).

Peer to peer is out due to your firewall constraint. This doesn't really work easily for directory services anyway.
The next easiest method I would use is to toss up a very simple CGI server script on one of the numerous super cheap web hosting sites. It seems that you don't want to go this route. Is there some particular reason? 100 lines of code and a super cheap server should give you everything you're asking for and more.
I suppose you could hook into some sort of third party chat library thing. I don't know about the current IM protocols, but good old IRC and a separate channel for your game would work. You even could cobble something together using FTP. BLOG comments on a free blog site would work too. The question is why?
These are all kludges. They get the job done in obtuse, inelegant, and poorly scaling ways.
I urge you to reconsider the web server solution.

You have a lot of conflicting requirements. Both clients behind a firewall blocking incoming requests pretty much means they can't do peer-2-peer since neither machine can act as the server, and you will need to have a transport server in the middle somewhere routing messages to each client. Right now what you are asking is pretty much not possible given the no server requirement.

Related

Is WebRTC too privacy invasive to use for video chat without TURN servers?

I'd like to implement a simple video chat system for students to tutor each other. I'm a one man show, and would like a system I can run in a cost effective way starting with 10 users, and hopefully scale up as needed.
WebRTC seems like a great, low latency, and cheap option to build this feature. However, if clients are communicating, then they must know each other's public IP. Is this a significant privacy or security issue?
What is the worst case scenario of somebody getting my IP address? Wouldn't any malicious actor have to get through my ISP to get my specific location?
Thanks!
If you host it yourself, WebRTC can be extremely cost-effective. I've been running the SFU at galene.org (disclaimer: I'm the main developer), which is used for multiple lectures with up to a hundred students. Even though this is a full-fledged SFU (and not a mere TURN server), hosting amounts to just over €6/month.
If your tutoring sessions involve just two or three people, then peer-to-peer WebRTC might be enough, but even then a TURN server will be required, especially if some of your users are on university networks. For larger groups, you will need to push your traffic through an SFU.
If you do peer-to-peer WebRTC, then any user can learn the IP of any user they are communicating with; this is most probably not an issue, since the IP addresses are most probably already being disclosed (e.g. in mail headers). If you go though an SFU, then the IP addresses are not deliberately disclosed, but they might still leak; for example, the SFU implementation mentioned above (Galene) discloses IP addresses when a user initiates a file transfer since file transfers happen directly between clients, in a peer-to-peer fashion. (It may be possible to avoid this disclosure by setting the iceTransportPolicy field to relay in the PeerConnection constructor, but I haven't tested how effective it is.)
WebRTC doesn't have to be P2P. You could run a SFU. Each user will upload their video to your server, and the server will distribute via WebRTC. Then the users will never know each others IPs.
I don't have any exact numbers, but it isn't expensive either. Your biggest expense will probably be bandwidth. Lots of Open Source SFUs exist, this is a good list to get started.

WhatsApp - How WhatsApp server stops/detects requests from unauthorized apps?

Every application that generates dynamic content must have a server whose address is embedded inside the application to enable communication with server.
Now in the case of WhatsApp definitely they have also embed the server's address inside the WhatsApp application. For example someone reverse engineer the WhatsApp apk and found the address of the server, as well as he also found the parameters and all the stuff that the application sends to the server (i-e session, token, authentication key etc etc) for successful communication, so is that mean he can use these same parameters structure and the server address in different third party app to play/communicate with the WhatsApp server? Because server is just an electronic device that works on the digital signals and thats it. Server don't know that these parameters are coming from the authorized WhatsApp apk or from third party apk.
If yes, then don't you guys think that there should be solution to that problem?
If no, then what are the techniques and algorithms they are using to stop requests from unauthorized/fake apps.
I believe not any employee from WhatsApp will answer here to share the algorithm, but i know SOF is full of geeks, if someone knows how WhatsApp stops these kind of issues please share, otherwise i will be still glad to know about the advice and ideas that you guys have in your mind for the best security practices.
How banking, paypal etc and messaging apps including WhatsApp works in that scenario and how they stop the issue that i described above?
Important:
I am not going to reverse engineer the WhatsApp, i am just creating a server and fighting with this issue to be solved to secure my server and only accept request from my app but stop requests from unauthorized/fake apps.
Thanks & respect to all in advance who will contribute.
There is no way to prevent malicious reverse-engineering, resulting in a fake app pretending to be the real thing. While you are working on your server, you need to do defensive programming, that is, your server shouldn't assume that the request was sent via the app. So, if you protect your server against all kinds of malicious and deliberate misuses, then your server is safe.
However, that's easier said than done, because your project is developed by a finite amount of people and - if it becomes successful then - the audience contains a swarm of smart bad people.
You will therefore need to detect a subset of features that you need to absolutely protect against misuses and prioritize testing and improving those, by thinking with the mind of a fictional hacker, who would like to either gain unearned profits or do harm to your project. Schizophrenic, I know, but you need to do that on the server. You also need to improve the security of less than critical features, but at a lower priority and log the requests you get, so if SHTF, then you will have at least a chance to deduce what caused it and how.
If the phone app is in your hands as well, then you might implement some additional authentication for each version, like generating a version token for each user that downloads your app. Since the version token generator algorithm would not be in the hands of hackers, they would have to solve that on a per user basis, which is extremely laborius to solve this for several users if done by hand and if they work it out in a way to make it automatic, their solution would be viable only for a version.
So, there is no 100% accuracy in this area, but you can make life very hard and miserable for people payed to hack through your application.

Would IRC Be a Good Medium for Game App Communication

If I were to create a mobile game, such as Go Fish, where a number of users could play, I need an easy way for all the apps to communicate. I don't want a user to need a google or other account to register.
I thought that IRC could be used. I realize I'd have to have a way of getting the clients to know about each other for a particular game, but would IRC be ok? Is that against the TOS? Is it an appropriate use of the service?
I want an easy, always-free way for apps to communicate with each other. Low volume messages, fairly quick response time. Completely anonymous.
IRC is just a simple protocol and games have been using it for chat for decades.
Its probably not ideal for a modern game though, particularly because it poorly handles users losing connection.
You also have to host the server as its not peer-to-peer or anything so it requires maintenance and isn't entirely free. You'd probably also need to customize the server for your needs anyway so requires further work.
That all said I'm not super familiar with alternatives in the space.

Can WebRTC help me create a virtual classroom?

I'm trying to create a virtual classroom. Since I'm not familiar with the web conferencing (or conferencing) terminology, I'm not sure if I'm understanding WebRTC's capabilities as I should.
I've looked in the examples for WebRTC, and all that I've found seem to be peer-to-peer connections. As I understand it, peer-to-peer connections are between two entities. However, virtual classrooms are different as far as I know; they require all parties to be connected to each other, so that when one user speaks/types, all users hear her.
Is such a thing possible with WebRTC? If so, what is it called and how can I read more about it?
Check out the open source Big Blue Button project (http://bigbluebutton.org/). They're currently Flash based but are actively moving towards webRTC. Rumor has it they'll be using Kurento as their MCU. They also have open source mobile (Android/iOS) application code.
According to http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/, such a thing is possible:
Beyond one-to-one: multi-party WebRTC
You may also want to take a look at Justin Uberti's proposed IETF standard for
a REST API for access to TURN Services.
It's easy to imagine use cases for media streaming that go beyond a simple
one-to-one call: for example, video conferencing between a group of colleagues,
or a public event with one speaker and hundreds (or millions) of viewers.
A WebRTC app can use multiple RTCPeerConnections so to that every endpoint
connects to every other endpoint in a mesh configuration. This is the approach
taken by apps such as talky.io, and works remarkably well for a small handful
of peers. Beyond that, processing and bandwidth consumption becomes excessive,
especially for mobile clients.
Maybe you can try searching in the webrtc google group
hope this helps

What is the best server side solution for a real-time GPS tracking system

Well, I tried to ask this question as a comment on this question, but I thought that maybe no one will notice it, so I decided to ask it as a separate one.
The question is about how to do real-time GPS tracking system things; if we have the following scenario:
Rather than connecting a GPS receiver to a PC, the user will have a mobile device with an integrated GPS receiver.
Location data will be sent over mobile network using GPRS data connection to a server side.
The data will be processed and a KML path file will be created and updated on time intervals and used to track the user using Google Earth.
The question is: what is the best method to accomplish this scenario for the server side; is it a web service, a web application, a windows service, a windows application or what exactly? Taking into account that the system will serve a number of users simultaneously, and that more users may use the system in the future(scalability issues).
Thank you in advance and I highly appreciate any help :)
What kind of device are you using exactly, something like this or something more sophisticated / configurable? If we assume that the device sends its data over TCP, I would consider the following approach with separate input/output processes:
Input: a process listening specific TCP port and storing incoming coordinates to database with a device id. Preferably, your listening loop must be able to handle simultaneous connections without them blocking each other.
Output: web application reading coordinates from database for a given device id and displaying them through the Google Earth API.
Use whatever programming language(s) you are familiar with.
For me there is a technical limitation/risk here -> the mobile device, and its connectivity.
1) What are your requirements? Do you need to support various mobile devices or will you focus on only one platform ?
2) More importantly, you have to understand that GPRS data connections differ from a PC connected to the Internet. There are various connection restrictions imposed by different mobile operators.
If I was to design such a system in order to minimise those risks I would go with a web server running on port 80 which the mobile devices would upload their Long/Lat through POST (or even GET to simplify things).
EDIT: Regarding scalability, it would be very easy to scale things up in the future using tried&tested load-balancing techniques.
EDIT2: Whichever technology you decide to use, i would HIGHLY recommend that the first thing you do is to mock up a prototype. Those connection restrictions could be show-stoppers. Ideally you need to explore them before you have made any serious investment.