My system is web-based crypto trading platform.
My front-end is Php/NodeJS, which allows user to place a stock order (a http form request)
A C++ written backend is written to send API calls to different exchanges.
Question, how to send the front-end form request to my back-end. I thought about two options but none are optimal
1) the C++ backend can also serve as a server to listen any POST message through TCP connection, then pass the messages to the trading engine. For exmaple, using socket.
2) UI send JSON messages to pusher(pusher.com), then a C++ pusher client listen to the channel to grab the messages and pass to the trading engine thread/process. Any reply needs a second channel to be sent as JSON message back to the frontend
For option 1), I am not comfortable make a C++ server as most times we use Java or Node based server
Any advice on those two options or other alternatives are welcome
Thanks.
After spending whole weekend researching and testing the various options, I have come up to the following options:
build a nodeJS server, then let NodeJS to communicate with C++ process. https://nodejs.org/api/addons.html
Related
I am trying to implement a very simple self-hosted (docker) pubsub client update system using websockets or SSE for my PHP application.
I would like that a specific javascript action on my website triggers a php server-side update (via ajax) which should then lead to an update to all subscribed devices for the particular channel/topic. The subscribed devices should use javascript listening to one channel each.
Do you know any simple PHP ws libraries which are capable of that? Can SSE be triggered in that way and also utilize channels? How about in-built PHP socket function? Ideally I would like to stick to PHP solution in order not to deal with translations and in-between REST APIs.
After researching this for days and going through solutions like RabbitMQ, Redis, Kafka, RatchetPHP, ZeroMQ, socket.io, RPC, SSE and etc I am completely lost. I need some guidance on which way to go.
Among all possible solutions here is how I would do it:
Install a web socket server, preferably implemented in PHP, on you Linux system.
Your web clients register with the server and listen for messages like broadcast from the server.
Your ajax script registers also with the server and sends a broadcast to the server if all work is done.
The server passes the broadcast to all registered clients.
You could use my implementation of such a web socket server that comes with all the needed client
libraries for JavaScript as well as for PHP that implement broadcast and feedback.
See https://github.com/napengam/phpWebSocketServer
I have a project were I am required to add push notification for Cordova AngularJS Push Notification using PHP on server side which gives JSON array as output. I can implement chat etc using this, but I want to know how to implement it in push notification or accessing native app API. Firstly I thought using Javascript SetInterval, but it slow downs the app, and checks the API everytime...
For Cordova push notification you can take a look here:
http://phonegappro.com/tutorials/apache-cordova-phonegap-push-notification-tutorial-part-1/
Still, let's review some other methods of sending data to the client using Web APIs:
Long polling - keep the connection open on the server side with no or long timeout, and return a result when you want to send a push notification.
Use WebSockets - open a steady TCP connection to the server and transmit messages in both directions (unlike HTTP's request/response model).
Use PushManager - this is an experimental technology that is not yet supported on mobile devices, so I guess this is a no-go for you.
Use simple polling - every now and then poll the server for a new message.
Long polling and Web Sockets will overload the server if you'll have a lot of concurrently open connections, so I wouldn't go there. Also Web sockets are mostly used for communicating between clients (server passes the client info to both clients, then they can communicate on their own without the sever intermediating between them).
PushManager is too new a technology not yet supported in mobile.
For what you want (mobile I guess, as you want to use Cordova), and without knowing what you are actually trying to achieve, I would say go with #4. I understand you already tried it, but perhaps try to lower the polling rate to every 30 seconds or so.
I understand that while debugging it doesn't seem nice to send something from the server then wait the better part of a 30 seconds period until it appears on the client, but if you think of it from the user's view point you'll see that the user doesn't know when the server sends the data, so it does appear immediate.
However, if you're writing a chat client, then I would go with web-sockets, using the server to connect the two (or more) clients in the chat and letting them pass the messages directly. If you want the chat to be server backed, just periodically send the transcript to the server using simple AJAX.
DIY vs Hosted Realtime Data Stream Network Service
If you do not expect to have more than a few thousand clients using your app, the DIY (do it yourself) sockets technologies (WebSockets, Socket.io, etc) is feasible. Beyond a few thousand (many of our customers say in the range of 5 to 10 thousand) you will experience difficulty (and large expense on server resources and scalable code) scaling your service.
Using a hosted realtime data stream network service like PubNub, Pusher, Ably, etc will be less costly and complex and it will just work. With some of the hosted services (PubNub for sure - which I work for - full disclosure) provides the ability to publish the message in realtime and include a push payload (for GCM, APNS and MPNS) that will also send the push notification if the app is in the background or not running.
With PubNub BLOCKS, you can also implement server side code that runs in the PubNub Network to inspect, manipulate or process the message without having your server do the work. This means you could send the message to other third party services: translate message to another language, use AI services for whatever reason, send an SMS/email/etc and much much more.
i'm trying to implement a chat application for android (where users can communicate people who are in same location). i'm thinking it of an facebook messenger with Geo specific oriented. i came across to terms like repeated pull, comet, bosh, websockects, socket programming, xmpp(which requires xmpp capable server like openfire) etc to do this. But my resources are fixed like apache, php (codeignter) and MySql only. I need to find the efficient to way to do this. Guys i need this. Please help me.
Thank you,
abbiya
The preferred approach on Android is Google Cloud Messaging.
Google Cloud Messaging for Android (GCM) is a service that allows you
to send data from your server to your users' Android-powered device.
This could be a lightweight message telling your app there is new data
to be fetched from the server (for instance, a movie uploaded by a
friend), or it could be a message containing up to 4kb of payload data
(so apps like instant messaging can consume the message directly).
The GCM service handles all aspects of queueing of messages and
delivery to the target Android application running on the target
device. GCM is completely free no matter how big your messaging needs
are, and there are no quotas.
Essentially, it works like this: Your server talks to Google, and Google pushes the message in real-time (or nearly so, as long as the device is powered on and connected to the Internet) to the Android device(s). There's a registration process that happens on the Android device the first time the app is installed (and at future points to revalidate the registration). In your Android app, it's your responsibility to send this registration ID to your server so you can store it for future use. Your server uses this registration ID when it wants to push a message to that device.
The communication protocol between your server and Google is JSON over HTTPS. Your server can use any languages/technologies, as long as it can communicate with Google's servers. A PHP/MySQL application can definitely meet the basic requirements for the service:
Before you can write client Android applications that use the GCM
feature, you must have an application server that meets the following
criteria:
Able to communicate with your client.
Able to fire off HTTPS requests to the GCM server.
Able to handle requests and resend then as needed, using exponential back-off.
Able to store the API key and client registration IDs.
On the client side, the Android device must be running API version 8 (Android 2.2) or later. Of course, it's also your Android app's responsibility to process incoming messages (using a BroadcastReceiver, as the Android system sends an Intent to your receiver whenever a message arrives), which allows you to handle messages however you want.
I am trying to setup my server so that I can have someone contact me through a chatbox on our website. Since I won't be there at all times to monitor the chats, I am trying to setup a system where the chat is routed through a websocket to my server (using PHP-Websockets) which is then sent to my phone via sms. This is all working correctly. I am having trouble wrapping my head around how my response can get back to the client side. When I respond to a text, Twilio will access any page that I specify with the sms message as a post variable. How can I pass this post message to my websocket (which is already running) where it can then send the message back to the client? Thanks for your help guys
Twilio communicates with your application via a WebHook call (HTTP request) when it receives your SMS.
Since PHP-WebSockets is running as a standalone process, and not as part of an existing web stack (e.g. Apache) then you'll need to have a few components in your setup:
PHP-WebSocket
Web server - serving up your HTML, CSS etc and also interacted with by the Twilio WebHook
A way for 1. and 2. to interact. This is usually achieved through some sort of message queue
Here's a sequence diagram that details the communication between the various components in your setup, as I see it:
Hopefully that clarifies the communication from Twilio, your web server, your WebSocket server and your client.
If this seems overly complicated then you could remove the requirement to have the WebSocket server and message queue by using a hosted service such as Pusher, who I work for. If that is the case then this using Pusher & Twilio tutorial should be useful. One of the main benefits here is that you can continue to think in terms of request and response, rather than having to think about cross component communications through message queues.
I was trying to develop a web based chat system using PHP. I created one with the combination of jQuery and PHP but this setup is using lot of network bandwidth as it is continuously sending / receiving data to check whether a new message has been received or not (currently every 1 second). So I need to develop a system that will automatically display the message once a message is received from the other end without the need of sending a request to the server to see if there is a new message received.
I read in many places that this can be done using Jabber. I am really new to this jabber technology, so any help creating a new Jabber based chat using PHP will be greatly appreciated.
Jabber (also known as XMPP) is more of a protocol, so it's not really the solution you're looking for.
HTML 5 web sockets are a great new technology to achieve this. Rather than polling to see if there are any messages, the server can "push" new messages to the browser.
The client side code is JavaScript. The server side can be anything implementing the web socket protocol. There are probably some PHP libraries to write the server side code, but I have written a few Ruby web socket servers using EventMachine and em-websocket.