For a Flutter web app, I'm using a package that creates its own HTTP client instance, communicating with some gateway.
Additionally I have my own server for the app.
Should I modify the package, to have both connections on the same instance?
Or should I have a HTTP client for every connection?
The benefit of reusing an instance of HttpClient is that Dart can then let a connection to stay open for later reuse in case you are going to make another request against the same server.
So I would in general recommend reusing a HttpClient instance if possible, but here are no issue in having multiple instances of it. Especially if the two instances are used to connect to different servers.
There can be several reasons for having multiple instances like e.g. you want different connection settings (e.g. timeout, user-agent, different handling of certificates) for different endpoints.
Related
I have a question related to Apache Storm. Currently we use some servers to implement Storm, our application needs facebook/Twitter tokens.
So we want to design like this: each token belongs to a specific server, when a bolt received tuple, it'll request a token which is specifically for that bolt running instance, this is to prevent token blocking if different servers use same token in a short time.
Anyone knows how to achieve this way, is there any way to know which servers of a running instance of bolt? Thanks a lot.
If you want one token per bolt instance then add an instance variable to your bolt class to hold that token and initialize/cleanup that token at the appropriate times in the bolt lifecycle.
If you want to have a token for each machine then you can create a Singleton bean to hold one token for the entire JVM. Note that if you want to have more than one worker on a single machine then you need to be happy with multiple tokens for each machine (one per JVM on the machine), or build a stand-alone middleware server that owns the token and which handles requests from multiple JVM's on the machine. Even if that is acceptable you'll still need to work out how to make all of the bolt instances in a single JVM/worker share the one token for that JVM.
Consider the tic-tac-toe game built with Nginx as a reverse proxy and having multiple Rails backends. Each client sets up a websocket connection with some Rails backends. If two clients playing a game are each connected to a different Rails backend, then a move sent to one backend needs to be routed to the other backend so it can be pushed on the other websocket as shown in the picture below.
In Rails what is the idiomatic way to communicate between two Rails backends?
In this situation you should setup separate WebSocket server and connect both users and Rails servers to it. This way you will be able to handle all users from one server without worrying about sharding.
In case of high traffic you could also setup several WebSocket servers and implement some kind of queue or message bus between them that will propagate new messages - for example master server that will only handle propagating messages and slave servers that will be connected to it and sent all messages received from users to it. Please note that in such configuration master server should not handle connection from users and server only for propagation of messages between slaves.
Finaly, answering your last question directly, there is usually no need to contact between Rails servers directly - as opposite to WebSocket servers they serve on request-response basis so exchanging informations via database is enough in most cases. If you really need immediate change then solutions like AMQP should help.
We currently have an .NET 4 application that consists of Windows Service running in the background and local or remote clients (only 1-3 normally).
The clients have a WPF GUI and need some data from the windows service. Therefore, we use WCF with NamedPipe binding for a local client and NetTcp binding for remote clients. This works, but we often have problems with endpoints that are not reachable (channel faulted or not found etc.). We already try to rebuild faulted connections but it seems to be pretty fragile...
Now enter Web Api: It looks like a HTTP based stack might be more robust (no channels, no endpoints, can be self-hosted in windows service as well). There seems to be no problems with broken channels because each request is handled individually. So if something fails, you just repeat the request. (And we have experience with ASP.NET MVC from other apps, so this not new to us).
Now we are thinking what might be our best bet. Is it better to "harden" our existing WCF service (one service interface with about 15 operations) or to move the interface to Web Api and run it as HTTP requests (with JSON data)? Performance is not our main issue here...
Any ideas?
Hartmut
I recommend you stick with WCF (SOAP) services for your WPF application rather than moving to the Web API. There are a number of reasons for this. First I think we need to consider what the new Web API is trying to address - namely to provide a framework for supporting RESTful/HTTP/hypermedia services. This is likely to be a good fit for building applications that make heavy use of HTTP such as web, mobile and JavaScript applications, where you want to maximise the "reach" or interopability of your services (irrespective of platform). This is not to say that you can't use it for WPF clients but in your case, where all traffic is local to your domain, it makes more sense to stick with your current implementation.
The binding choices you have made for your services / clients sound ok to me. I would focus on why your channels are faulting and address these issues. You may also want to consider hosting your services via IIS and use WAS to expose your non-HTTP endpoints. I have had much success with this in the past and for the most part has been pretty stable. It also takes away a few of the headaches with managing your own host. If you are concerned about the TCP binding faults, then just create a new HTTP or wsHTTP endpoint and use that instead. This will provide you exactly the same transport the web api uses without having to change your programming model.
I have an existing complex website built using ASP.NET MVC, including a database backend, data layer, as well as the Web UI layer. Rebuilding this website in another language is not a feasible option.
There are some UI elements on some views (client side) which would benefit from live interactivity, involving both push and pull, so rather than implement some kind of custom long polling or websocket server in asp.net, I am looking to leverage node.js for Windows, and Socket.io.
My problem is that I need two way communication between both applications. Each user should only be able to receive data once they are authorised on the ASP.NET website, so I first need communication for this. Secondly, once certain events occur on the ASP.NET website I want to immediately push this data to the Node server, to be broadcast to specific users or groups of users. Thirdly, I would like any data sent to the node.js server to be pushed to the ASP.NET website for processing, as this is where all our business logic lies. The sole reason for adding Node.js is to have the possibility to push data directly to the client, I do not want to build any business logic into it (or as little as possible).
I would like to know what the fastest method of two-way push communication is between Node.Js and ASP.NET. The only good option I'm aware of so far is to create a special listener on a specific port on the node.js server and connect to that, but I was wondering if there's a more elegant or more efficient method? I also know that you could use a database inbetween but surely this would need to be polled and would be less efficient? Both servers will be running on the same server under a Visual Studio project.
Many thanks for any help you can provide.
I'm not an ASP.NET expert, but I think there are multiple ways you can achieve this:
1) As you said, you could make Node listen on a specific port for data and then react based on the data received (TCP)
2) You can make POST requests to Node.js (HTTP) and also send an auth-key in the process to be extra-secure. Like on 1) Node would react to the data you send.
3) Use something like Redis for pub-sub, send messages from ASP.NET (pub) and get them on the Node.js part (sub). This is even better if you want to scale your app across multiple machines etc.
The only good option I'm aware of so far is to create a special
listener on a specific port on the node.js server and connect to that,
but I was wondering if there's a more elegant or more efficient
method?
You can try to look at redis pub/sub model where ASP.NET MVC application and node.js would communicate through separate channels in order to achieve full-duplex communication. Or you can also try to use CouchDB change nofitications.
I also know that you could use a database inbetween but surely this
would need to be polled and would be less efficient?
Former techniques do not require you to poll for changes, but instead they will notify you when the changes happens or channel message arrives.
As I begin building the framework of my first iPhone app, I'd like to learn more about the "standard" or preferred approach for interacting with HTTP servers. I assume most of these iPhone apps initiate HTTP connections to send and receive data. What is the preferred data format and method for going about this task?
Secondary questions: Are there other ways of sending/receiving data to a server? Should I avoid using a PHP web server as the middle man in interacting with a few databases?
Current process:
Outbound: iOS -> Http request -> PHP -> MySQL Database
Inbound: MySQL -> PHP -> JSON Data -> iOS
I would use XML to communicate with your server unless you are doing something special (Video/Audio or packaging your own data). Cocoa has built-in support for XML so it would speed up the development process.
There are other ways to communicate with the server. You could write your own protocol which would only be understood by your client (Maximum security but could be hard to maintain or bugs could be discovered). You could use someone else's framework (like JSON).
For more details about JSON, please see this link iPhone/iOS JSON parsing tutorial
You could try NSURLConnection. It is usually your best bet. It's the preferred method to access web resources. Be sure to check out NSURLConnection SSL HTTP Basic Auth to see how to use SSL. If your're debugging and your certificate is not quite trusted, check out: How to use NSURLConnection to connect with SSL for an untrusted cert?.
As for your Database question.
I personally would use a PHP Webserver that communicates directly with my Database because
1. I can change web hosting companies and my iOS app will only need to know the domain name (www.example.com/?username=abc&password=0000&uuid=000000&data=PackagedData)
2. I can upgrade my DB plan from FREE to something that can manage more connections (or the type of DB) and I just need to update the connection strings in my PHP Script (no need to update client iOS app)
Here are some scary reasons why you don't want direct communication with your database server
1. If you are storing sensitive non public data (usernames, documents, passwords, etc) then you're taking a HUGE risk. A clever hacker can reverse engineer your app and find the strings you used to connect to the DB and then gain access to your DB (without your knowledge). Possibly use the data or sell it!
If you ever decide to choose a new DB server or if your hosting company decides to give you a new IP (or sub domain for your DB Server) then you will have to update ALL your clients immediately and you may need to send them Push notifications to inform them that your App will stop working unless they upgrade.
There isn't a preferred format. Personally I like using JSON but some people swear by plists because of the speed. You can also use XML if you are more comfortable with it. I've found working with JSON REST API's very enjoyable on iOS using ASIHTTPRequest and JSONKit. It's been pretty easy to get started and the flexibility allows for some really cool stuff.
You should definitely use a PHP Server as the 'middleman' because you'd want to validate your data on the server side as you receive it. Exposing your DB directly exposes it to attacks and using PHP you could save yourself a lot of headaches and issues. Of course you can use other frameworks and languages such as Ruby (RoR, Sinatra etc.), Python (Django) and others
Your current process looks just fine to me and is what many services on the Web use to solve this exact problem.