Just wondering if anyone can help me understand the advantages of talking to Arango via HTTP or the driver? In my case the GoLang driver.
Aside from the few milliseconds overhead per request,would I experience a big difference in performance?
I like the concurrency attributes of using HTTP Requests, since my main tools all make HTTP communication very easy.
Thanks for any insights on this subject.
Quick scanning through the 3 recommended drivers shows they use HTTP under the hood.
So using them will not give you big difference in DB interaction, but may be more comfortable for development.
Related
I'm currently building a Koa app with the Firebase Node library. Is there a speed difference between using that compared to REST?
This is something that would best be determined by some profiling or jsperf-style testing.
The simplest answer is that there would naturally be a difference, particularly at higher frequencies of transcations. The node.js SDK works over a socket connection, whereas the REST client would have the overhead of establishing and tearing down connections with each payload.
One helpful tool that can help narrow the gap in performance is to utilize HTTP 1.1's keep-alive feature. However, it's certainly not going to be comparable to web sockets.
Firebase is a web-socket real-time database provider, so it's much more faster than HTTP REST calls, that has a big overhead of creating a new connection for each call, so you can use this link below to have an idea:
http://blog.arungupta.me/2014/02/rest-vs-websocket-comparison-benchmarks/
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
I've just started dabbling in some game development and wanted to create a simple multiplayer game. Is it feasible to use HTTP as the primary communication protocol for a multiplayer Game.
My game will not be making several requests a second but rather a a request every few seconds. The client will be a mobile device.
The reason I'm asking is, I thought it may be interesting to try using Tornado which reportedly scales well and supports non blocking requests and can handle "thousands of concurrent users".
So my client could make a HTTP Request, and when the game server has somethign to tell it, it will respond to the request. I believe this illustrates what some people call the COMET design pattern.
I understand that working at the socket level has less overhead but I am just wondering if this would be feasible at all given my game requirements? Or am I just thinking crazy?
Thanks in advance.
Q: Is it feasible to use HTTP as the primary communication protocol for a multiplayer Game.
A. Using HTTP as a communication protocol may make sense for your game, probably not, but that's for you to decide. I have developed applications for Windows Mobile, Blackberry, Android and iPhone for just over 10 years. All the way back to CE 1.0. With that in mind, here is my opinion.
First I suggest reading RFC 3205 as Teddy suggested. It explains the reasons for my suggestions in detail.
In general HTTP is good because...
If you're developing a browser based game - flash or javascript where you don't create the client, then use HTTP because it's built in anyway and it's likely all you can use.
You can get http server hosting with decent scripting super cheap anywhere
There's a ton of tools available and lots of documentation
It's easy to get started
HTTP may be bad because...
HTTP introduces huge overhead in terms of bandwidth compared to a simple TCP service.
For example Omegle.com sends 420 bytes of header data to send a 9 byte payload.
If you really need comet / long polling you'll waste a lot of time figuring out how to make your server talk right instead of working on what it says.
A steady stream of http traffic may overload mobile devices in both processing and bandwidth, giving you less resources to devote to your game performance.
You may not think you know how to create your own TCP server - but it really is easy.
If you're writing the server AND the client, then I would go straight to TCP. If you already know python then use the twisted networking library. You can get a simple server up in an hour or so just following the tutorials.
Check out the LineReceiver example for a super simple server you can test with any telnet client.
http://twistedmatrix.com/projects/core/documentation/howto/servers.html
WRT:
"my client could make a HTTP Request, and when the game server has somethign to tell it, it will respond to the request."
This is not how HTTP is supposed to work. So, no, HTTP would not be a good choice here. HTTP requests timeout if the response is not received back with the timeout (60 seconds is a common default but it would depend on the specifics).
Please read RFC 3205: On the use of HTTP as a Substrate, which deals with this.
With the target platform being a mobile device (and the limited bandwidth that entails) HTTP wouldn't be the first tool I would pull out of the box.
If you just fancy playing with all this technology, then you could give it a go. Tornado seems like a reasonable choice, if the example on the web site is anything to go by. But any simple server-side web language would suffice for serving up the responses you need at the rate you have mentioned. The performance characteristics are likely to be irrelevant here.
The COMET method is when you leave a HTTP connection open over a long period. It is primarily there for 'server push' of data. But usually you don't need this. It's usually much more straightforward to make repeated requests and handle the responses individually.
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 in the process of building a test plan for validating the security of our Flex/J2EE application. I believe we have some issues with trusting the Flex application too much, but I need to be able to quantify those issues.
The ideal way would be a way to show me making data service calls outside of the application. Are there tools or instructions for how one might go about doing this? I really don't want to find these things out after we release to our beta customers. :)
Charles is an excellent HTTP debugging proxy which can parse AMF data and display it as a tree. You can also set "breakpoints" to intercept a HTTP call and modify the AMF data in either the request or response.
http://www.charlesproxy.com/
Fiddler on Windows is great for monitoring http connections.
First, give the port on which Flex communicates to the J2EE server, then using Ethereal or Wireshark you can watch if it use an encrypted channel :-)