Announcement: Pond

[AireTamStorm]

*Logo Designed by greendots*
Well, I've spoken alot about how important online is for the Pandora, and now I'm going to put my money where my mouth is.
I'm announcing my plans to write a network library to take the complexity out of integrating online functionality into homebrew games, emulators, and applications: The Pandora Online Network Library, and its server Daemon, POND. I aim to have this library in preliminary form for development by the end of this year. I know there are other project(s) out there with similar goals, but I think that if I want it to happen, I need to make it happen myself.

The Current Design Plan
POND will a Jabber Server that takes and parses XML to negotiate connections between multiple clients. You can connect to POND like any other Jabber Server with any client, but when PONClient connects it throws an XML snip over to indicate that it is PON Library compliant. The server will then negotiate with that client to create connections with other PONClients. If a PC user connects, POND does not communicate the XML negotiation with it. In reverse, this means PONClient can connect to normal Jabber Servers, and send the XML negotiation directly to the other PONClients, since normal servers will just pass that information right through.

The Goal
All an application would need to do in order to be POND connected is to include the libraries and call a connect function. For example, Two Pandoras negotiate and try to connect to each other, however both are behind NAT and firewalled. PONClient will include UPnP to automatically forward ports of course, but if that process fails, the Jabber Server is told to create a tunnel on a remote server. This tunnel is created, the Pandoras are given the connection information, each unit connects to the tunnel. All the developer needs to do, is call a simple function to send and receive data for their application. No proprietary server needs to be coded. As long as the application is network enabled, it just works based on Jabber name. As a bonus, you get standardized chat. But that doesn't stop you as a developer from using proprietary chat over the data pipe that is created by POND. The tunnel servers are separate. They can be run on the POND server, or on separate machines and networks.

Who this is for
PONL is going to be a network library for use by developers. There will be a frontend interface for configuring things (example: which POND/Jabber server to connect to by default), and a small chat client for the end user. But as a developer, you're not forced into anything. You can use POND /just/ as a means of connection if you want. Or, you can go all the way and make use of certain file transfer and text chat functions. This will be a library primarily coded in C / C++, but I will include preliminary Python bindings for those who want to create a quick app or game and still want to do something really cool.

Basic functionality I plan to integrate:
Chat: Text, and later Voice
Automatic connection negotiation
Application / Firmware update notification options
File transfers
Bug Reports
Global configuration UI

So thats the details I have for now, but now I need to know what your opinions are on this.

I really want to hear a lot of feedback on this. I want to do it right. Most of all, I want to see the adoption of online functionality in the Pandora space. This is not a standalone product, and it never will be. You're the developers. If I can get ONE of you to make the decision to bring your game online, this effort would be plenty of a success.

Couple things I want to know from the development community here:
When coding homebrew (games, apps) with network support, what proves to be the biggest obstacle?
When do you decide whether or not to enable online functionality in your applications or games?
What kind of features would you expect to see out of a network library like this?
Beyond that, any suggestions?

 

[Izomiac]

Sounds like a solid and useful idea. My only suggestion would be falling back onto UDP Hole Punching for NAT'd connections before using an external server so as to reduce latency and server load.

 

[conso]

I love the idea and I would totally vote for making this not ONLY for pandora. It would be a bless for jabber to have such an extension in it's portfolio and become a connection between gamers all around the world, be it for shooters or classic puzzle games.
Jabber already has so many great features, like shared rosters, that make it easy to build up a dedicated community, it would be a shame, if we wouldn't make use of it

 

[sindbad]

I hope this becomes as popular as Jingle (could you use some of their nat/firewall transversal code?). You need a better name for that, though.

 

[teppic]

It would be great if also local connections could be supported without the need for internet access. This could probably be done with zeroconf.

It doesn't really need all the features from the jabber-version. A simple list of hosted games would be enough i think.

 

[u9i]

Sounds like a well thought out plan. But is it necessary to have a jabber account to use it? I honestly don't know anyone who has such an account.

 

[conso]

Sounds like a well thought out plan. But is it necessary to have a jabber account to use it? I honestly don't know anyone who has such an account.

Registering a jabber-account is as easy as choosing one of the servers, typing in a nickname and a password. That's it. What's the problem?
You also know probably a lot of people with a jabber-account, like everyone who as a mail-account at web, freenet, gmail and several other mail-services.

 

[sindbad]

I didn't notice the first time around that you plan to add voice at some point. In that case, you REALLY should use libjingle.

 

[conso]

I didn't notice the first time around that you plan to add voice at some point. In that case, you REALLY should use libjingle.

I really hope there is a way to use a jabber-client to launch and connect a game directly, at least for desktop-usage.
Say I chat with my brother over jabber. I make a right-click on his name in kopete/pidgin/etc. and select "start a game" I get a list of configured games, choose one of those and as soon as he accepts the invitation, the game gets started and connects. Would be awesome

 

[AireTamStorm]

For voice, I was just planning on using speex, then sending that over the pipe. I'll look into libjingle. As for UDP hole punching, that looks very promising. And don't worry, if you want to compile your application for the Pandora, PC (Win, Lin or Mac), it will work, and all versions will be compatible with eachother. So your Pandora users can play with your PC users, and vice versa. You're not restricted to any platform in particular. Do note though, that it will probably only work on Linux for the initial releases. We'll port once we have something to port : ) .

For LAN connections, Zeroconf isn't a bad way to do it. I was planning some sort of LAN functionality but didn't really have a good idea where to go with it.

I may write a pidgin plugin to assist in game launching, but my top priority is getting the network library working and bulletproof.

I have another guy that is going to work on this with me. we're in the design phases right now, so any feedback like above directly influences the final product. Name suggestions, maybe a little logo or something, how you want the interfaces to behave, etc.

Thanks for the positive feedback so far!

 

[sindbad]

Jingle is very cool because, like skype, it can puch through pretty much any network setting, no matter how weird. It can be and has been used for audio calls, webcam, files and much more. Also has a very flexible license. If you can use it, you will save yourself a lot of work and trouble.

Maybe even the game networking can be done over Jingle, but I don't know enough specifics so it may be impractical.

How's Joy for a name? Goes with Jabber and Jingle.

PS: I may (stress on may) be able to help with the python binding.

 

[multiplex]

So basically it will provide a simple means of connecting clients based on a Jabber account, + some utility abstractions on top?

I assume you could use both TCP and UDP, and that you could broadcast a message to a group of peers. Maybe joining and leaving a group could be handled as well.
I'd also expect clients to be able to connect to each other on a LAN, e.g. on an ad-hoc network with no internet access. And at that point, you might as well support connecting two clients based on a know IP and port, which could be useful if you wanted to launch the game from some other application that didn't require a Jabber account.

The largest problem with creating any P2P capable app today is of course that the internet is broken. :angry:
IPv6, please come and save us all!
I'll admit, if left to create my own network code, I'd just say screw everyone who can't set up their own port forwarding.

I hadn't heard of libjingle before, but the core functionality of establishing a connection over XMPP does seem similar to yours.

Is this a competitor to that recursive acronym thing, or more of a complementary thing?

 

[sindbad]

Jingle is an extension to the jabber protocol made by google for it's google talk audio calling feature. It's written only with bits of pure coolness and has been or is being integrated in many open source IM clients.

 

[PSyMastR]

This looks quite incredible. I would totally integrate it into an upcoming project of mine. If you need help coding a web interface for the server, such as who's online now and stuff. I would be more then happy to help.

 

[dentrado]

Sounds really good, have you thought about how this could be integrated with TINXL?

 

[AireTamStorm]

Is this a competitor to that recursive acronym thing, or more of a complementary thing?
This is a competitor to TINXL. TINXL more seems focused on the community aspect rather than the under-the-hood functionality, though. If POND gets to a mature state the creators of TINXL could use POND as a means of connection. If TINXL does end up doing do many of things I've boasted for a featureset, there may be a possibility of future interconnectivity. Right now, I want to get my own stuff running.

It comes down to the fact that I'm using alot more existing standards. This sounds impressive on a level, but really most of this code it already written for me. I'll just write the appropriate server plugins for a GPL'd Jabber server and redistribute the source so that anyone can host, compile, or modify a server. The client is the biggest about of work, but libpurple makes up for ALL of the communication connection code. Beyond that, standard TCP / UDP and APF for the port forwarding. I'm just gluing a bunch of projects together.

Now, I need to figure out which GPL'd Jabber Server to use : )

For people who do not want to release their code via GPL: I will have a wrapper available to separate GPL'd code from PONC. PONC will likely be a daemon and the code you plop into your application will be public domain. This also allows for PONC to be updated by itself.

@PSyPastR:

Not quite there yet, but if you can code web interfaces it would be a big plus for server management.

 

[MarcelP102]

This could be very usefull! Can't wait to play some old classics against other pandora users

 

[___]

only thing that I'd want would be some sort of online score tracking implemented for multiplayer matches... but I guess that goes a little too far as we'd need a server and someone who maintains it.

I really like your idea though. I thought about something similar recently and you basically read my mind. Hope you are getting somewhere with your concept. I am sure there is a lot of people willing to help out with code and such.

 

[Mithrildor]

Great! That would be nice. Just 5 things

1. IRC client!
2. Being able to chat on IRC/it's own chat when searching for games.
3. Being able to search for matchs for multiple games
4. Inbuild updater (to update all your games)
5. Gamertags, show others your skills and how much games you won on a tag.

 

[conso]

:huh: Jabber has it's own, much more powerfull multi-user-chat implemented! It's called MUC ^^ - IRC is completely unnecessery here, but maybe there is some way to tunnel a MUC through IRC.