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
Related
I don't know where to start especially with what programming language and in what kind of environment. I know I would need 2 different types, a server which receives requests and sends the requested material back and a client which sends requests and views requested material but not sure where and how to start.
Thank you
What is the motivation for this? HTTP/HTTPS are very tried, true and secure protocols that every (almost every) web application communicates via.
I cannot fathom a possible reason to create your own, especially if it seems like you are not quite experienced enough to do so given the very generic question.
My answer would be, don't do this, use HTTP/HTTPs or WebSockets, whatever suits your applications requirements.
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]
I want to build a decentralized, reddit-like system using P2P. Basically, I want to retain the basic capabilities of reddit, but make it decentralized, to make it more robust and immune to censorship. This will also allow people to develop different clients to match the way they want to browse it.
Could you recommend good p2p libraries to base my work on? They should be open-source, cross-platform, robust and easy to use. I don't care much about the language, I can adapt.
Disclaimer: warning, self-promotion here !!!
Have you considered JXTA's latest release? It is probably sufficient for what you want to do. Else, we are working on a new P2P framework called Chaupal, but it is not operational yet.
EDIT
There is also what I call the quick-and-dirty UDP solution (which is not so dirty after all, I should call it minimal).
Just implement one server with a public address and start listening for UPD.
Peers located behind NATs contact the server which can read how their private IP address has been translated into a public IP address from the received datagrams.
You send that information back to the peer who can forward it to other peers. The server can also help exchanging this information between peers.
Then peers can communicate directly (one-to-one) by sending datagrams to these translated addresses.
Simple, easy to implement, but does not cover for lost datagrams, replays, out-of-order etc... (i.e., the typical stuff that TCP solves for you at the IP stack level).
I haven't had a chance to use it, but Telehash seems to have been made for this kind of application. Peer2Peer apps have a particular challenge dealing with the restrictions of firewalls... since Telehash is based on UDP, it's well suited for hole-punching through firewalls.
EDIT for static_rtti's comment:
If code velocity is a requirement libjingle has a lot of effort going into it, but is primarily geared towards XMPP. You can port off parts of the ICE code and at least get hole-punching. See the libjingle architecture overview for details about their implementation.
Check out CouchDB. It's a decentralized web app platform that uses an HTTP API. People have used it to create "CouchApps" which are decentralized CouchDB-based applications that can spread in a viral nature to other CouchDB servers. All you need to know to write CouchApps is Javascript and learn the CouchDB API. You can read this free online book to learn more: http://guide.couchdb.org
The secret sauce to CouchDB is a Master-to-Master replication protocol that lets information spread like a virus. When I attended the first CouchConf, they demonstrated how efficient this is by throwing a "Couch Party" (which is where you have a room full of people replicating to the person next to them simulating an ad hoc network).
Also, all the code that makes a CouchApp work is public by default in special entities known as Design Documents.
P.S. I've been thinking of doing a similar project, but I don't have a lot of time to devote to it at the moment. GOD SPEED MY BOY!
What is the correct way (or best) way to implement Comet, HTTP Push, or Reverse AJAX?
What .NET implementations would you recommend?
I have hear about, WebSync and PokeIn, both are paid implementations, I have used PokeIn and its pretty straight forward. If you are looking forward to code your own COMET implementation, I just can say that its a complex task, because you need to modify the natural behaviour if IIS. Its a hacky way to get around the limitations of the HTTP protocol and you need to know really well what you doing so don't end up breaking things around =).
It's also known as long-lived
requests. This is also by far the most
complex method to implement.
Basically, a request is made by the
client, and the server very slowly
responds, which causes the connection
to be maintained. Periodically, when
the server has something to push,
it'll "burst" send the information, so
to speak. This approach gives you
real-time push, which is great. But,
it has a serious down-side: holding
connections open like that isn't how
the underlying protocols are meant to
work, and most servers aren't terribly
happy about it. If your traffic gets
too great, you'll chew up threads on
the server and wind up bringing your
site down.
ref: http://www.coderanch.com/t/121668/HTML-JavaScript/does-Reverse-Ajax-Works
JOBG is correct re: the complexities; it's probably not a task you want to undertake lightly. I'm one of the authors of WebSync, and I can attest that it's a difficult task.
There are a ton of examples in the download, and the community edition is free.
Microsoft is developing HTTP push in SignalR
https://github.com/SignalR/SignalR
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).