I am completely new to web development, so please forgive me in case this question is superfluous.
Here is what I am trying to do:
I have multiple Arduinos (equipped w/ EthernetShields) that are collecting and displaying data (using sensors and LCD screens). All Arduinos communicate with a webserver hosting a MySQL database and a webpage visualizing the data. The Arduinos are themselves capable of hosting minimalistic webservers that can run some simple html/php/etc...
My question is:
What is the most straightforward way to implement the communication between the Arduinos and the main server, so that I can send data back and forth between them, without any user interaction?
The data consists of relatively few integer values and short strings of text. Security is not an issue.
Edit for clarity:
How to continuously send data back and forth between two web-servers?
Assuming that I use PHP, what is a simple way to do this? All tutorials for the GET and POST methods included the use of 'form action', which to my understanding requires user interaction.
If I understand you right, you have a central web server that needs to communicate with a whole bunch of arduinos. You need to send information in both directions between the arduinos and the central server. And, you want to use web (http / tcp / ip ) protocol to do this.
You face a choice:
Do you want to have the central server initiate the communication? Or do you want to have each arduino initiate the communication?
I think the second choice is pretty good. It means that you can add new arduinos to your system without somehow reconfiguring the central server. But, I don't know much about your application so there might be some reason this is a bad idea.
So, what you do is implement a simple web CLIENT (not a browser) on each arduino. Then, on a regular schedule you have the each arduino do a web request to the main server. Depending on the amount of data you need to send from the arduino to the server, you can use a GET or a POST. If the data is small, you can use a GET request. For example if it's temp and humidity you can send the request like this once a second.
http://server/upload.php?temp=65&humidity=78
In response to this, the central server can handle this data correctly. You'll be able to tell which arduino it's from by the client internet address REMOTE_ADDR.
Then, the server sends a response that contains whatever data the server needs to send to the arduino.
See how this goes? each second each arduino hits the web server saying "here's what I have for you. What have you got for me?"
Related
I am writing an application with a Flex/as3 client. The client needs to send some data (at this point an xml file roughly 10 KB but later could balloon to up to 100 KB) to the server every minute or so and then receive another similar xml file back. The server's job is to validate the data in the xml file and possibly update a mysql database. Some other Flex/as3 clients that are in the same "group" as the client which sends data (and clients can join/leave a group anytime) need to be notified when the server processes the xml file so they can then chose whether to download the file. There can be several such groups of clients (and clients from different groups don't talk to each other). Since I am somewhat familiar with php I would prefer to use this for the server-side script.
My questions are the following:
1) Would it be best to write this as a socket application? Or should this be just POST data sent to a web script?
2) If this is sent to a web script as just some POST data, how can I ensure that other clients get notified? Do I just ping my script every few seconds (sounds resource intensive)...
3) Is there some framework/libraries that I should use (on client or server side) to facilitate developing this?
I appreciate your help,
Ilya
Your best option is to use a socket connection. Normal POST data will be both slow and taxing. If you insist on it, I've done it before and can tell you how, but ultiamtely this should be easier: http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7cfb.html
I am building a website in PHP that handles the sessions in Redis in JSON format.
This way the session can be accessed by both the PHP interpreter and a node.js server.
What I am trying to do is now to add notifications in said website; the procedure I was thinking of is the following: (just figure it as a simple friend request to simplify it all)
user A sends friend request.
PHP uses cURL to say to node.js service to send notification
user B gets a notification because he is connected to node.js via socket.io
What are the general guidelines to achieve this? Because it looks clear to me that if user A and B are in different servers, it will be impossible to scale horizontally;
Thanks in advance.
Sounds like a you could make use of Web Sockets here with a Publication / Subscription protocol, architecture.
You get Server client functionality with web sockets.
Node is a perfect choice for a websocket server, lots of small IO.
See http://en.wikipedia.org/wiki/Web_sockets
I'm wouldn't think if the shared session is required for php - node communication, just have your clients push requests through the socket and handle the reposes as needed.
I think the approach you propose sounds quite reasonable. However, instead of doing a direct request to the service, you could consider using a message queue (zeromq, rabbitmq, whatever) which would allow you to scale it more easily as you can easily add logic to the queue processing to pass the message to the correct node instance.
I managed to get 1400 concurrent connections with socket.io on a cheap VPS with no special configuration so even with no tricks it should scale quite well. In my case most of these connections were also sending and receiving data almost constantly. It could probably have handled more than that, 1400'ish was simply the max number of users I happened to get.
Though I'd worry more about getting all those users first ;)
Use Redis's built in pub-sub capability. When the PHP server gets a request, it publishes it to a channel set up for that purpose. Each of your node servers subscribes to that channel and checks if the user involved is connected to it. If so, it sends the notification via socket.io. As a bonus, you avoid an extra network connection and your overall logic is simplified.
simply setup ur database as per required then whenever a activity is made just tell ur node js to transfer the related information through redis to php and make a process and in make a response back from php to node via channel keep checking the notification from table and show
Hi,
From the image above, I have a webserver a linux machine and client/device.. Now i need for this 3 to communicate. The webserver sends data to an ip address(client/device) based on button pressed on the webpage. but before the data is sent, the data must first access the linux machine, the machine then sends the data down to the device which then the device reads the data and act based on the command sent.. then the device sends back data to the linux machine which then the linux machine sends it to the webserver for ack'd. meaning data is received by the device without any problems.
Php is for the webserver. Now how will php sends data to an ip adress.
The linux machine handles all requests and sends everything down to the device and when the device got the data it will send a data to linux machine which then machine sends an ok to the webserver that the data arrived succesfully.(I read about socket programming and i think of creating an application that reads requests.) or if you have any idea how can i do this?.
How can the device read a data sent by the webserver?..
Thanks,
EDIT: The device is not connected to the linux machine. the device is only connnected via the ethernet cable.
Let's call the topmost machine 'Server', the middle machine 'Controller' and the bottom machine 'Device'. It does not matter if the device is a peripheral (say, USB or serial device), or a computer.
The first task is to get the Controller to query the Device. The best way to do this really depends on the Device. If you consider things like USB audio/video devices, they need to be tuned, then they send a continuous stream of data. Things like temperature or humidity sensors are told to do a measurement, then they respond with data.
Usually you write the required functions into a small library, and verify it works using command line tools. In some cases the library may not be necessary, for example if the Device is already supported by the kernel in Controller, and the information is trivially available. (For example, consider the temperature sensors in hard drives: if Device(s) are hard disks, then Controller can simply use the command hddtemp /dev/sda to get the temperature of the /dev/sda (first SATA/ATA/SCSI hard disk). I'd expect the end user to be able to pick which hard disks she is interested in, so that choice would have to flow from Server to Controller.)
Next, you write a service that will run on the Controller. This service will incorporate the library functions already written and tested, so it can easily access the Device. (This way you know the Controller-Device communication works, and don't need to worry about it. One thing at a time.)
There are many different designs for the service, from plain TCP/IP or UDP/IP sockets to Remote Procedure Calls (RPC), to high-level protocols like HTTP. In recent years, the last, using HTTP, has become more and more common, with responses being XML, plain text, or binary media (usually images). The idea is to have the service be basically just another web server that can access the Device directly. Security is simpler, because it does not need to be world-accessible: it can very well only answer to requests coming from the Server only. I've written such services using basic shell scripting (Bash), PHP (both PHP-CGI and command-line PHP, PHP-CLI), and C, among others. The best choice depends on the details, really. I personally prefer either a simple text-based TCP/IP socket, or HTTP.
On the Server, you can write a PHP page, that connects to Controller, requesting whatever it wants to request (usually depends on user data, first checked for sanity and safety, of course). PHP has easy built-in facilities for doing both HTTP requests and connecting using raw TCP/IP, so it suits quite well for this. If HTTP protocol wrappers are enabled, then it is just $handle = fopen("http://192.168.x.x/myservice?param1=" . urlencode($param1) . "¶m2=" . urlencode($param2), "r+b");. To get a socket connection, you use the fsockopen() function instead. (For details, see fopen(), http wrappers, and fsockopen() at the PHP Function Reference at www.php.net.)
In practice the PHP page code first creates a connection to the Controller. Then it sends a request, containing the relevant sanitized commands/parameters received from the end user. Then it waits for the Controller to respond with the results (by simply reading the response), then closes the connection. The response should contain all the data needed, so the PHP page is free to construct the page to the end user.
None of this is really difficult, but there is a lot to do. I've found the Controller-Device communication to require the most work; after that is done, the rest has always been quite straightforward.
If you can provide more details what the Controller-Device connection is, what kind of data (text? numbers? images? a lot of binary data?) the Device provides, and what kind of parameters/commands (just "one result, please?", basic commands like "move up", "where are you?") do you expect you need to send to the Controller/Device, I could perhaps be more specific.
Also, are you limited to PHP, or would you be comfortable writing the Controller service using C? I've found that to be a very good combination myself.
Edited to add:
In a nutshell, the three points can be answered as follows:
Either using fopen("http://ip.add.re.ss:port/", "r+b"); if using the HTTP protocol and PHP is configured to allow http wrappers (they usually are), or using fsockopen(). See the PHP documentation linked above for details.
With an IP-connected Device, Controller is basically a relay or translator. Usually this means a daemon running on Controller, managing incoming requests from Server (or Servers), and responses from Device (or Devices). This is more common when there are a varying number of Devices, and/or more than one interface is needed. In practice, the Controller runs a daemon just like described above, except the protocols may be standard or simple enough so there is no need to write a library.
The PHP running on the Server must contain the request details (exactly what is desired) to the Controller. The Controller must pass them on to the Device. If the Controller provides a http URL for the PHPs on the server connect to, it can parse the query parameters, and translate them into a format the Device understands.
One particular issue in practice is to handle concurrent accesses. There is usually only a single connection from Controller to Device, but more than one PHP might connect to the Controller simultaneously. So there is some book-keeping involved.
In some cases the Device provides a continuous stream of data (or regular updates of data) to the Controller, and the Controller simply keeps tabs on it. When a PHP running on the Server queries something from the Controller, the Controller simply looks up the latest data (without contacting the Device at all, just receiving the data as normal), and responds with it. Here, it is common to include a timestamp, or better yet, the age of the data, in the response from Controller to Server.
You really should add some details to your question. (I suspect the downvote is due to lack of details.) You don't need to tell us the exact make and model of the Device, only whether it is a receiver (TV? radio? weather station?) or a sensor cluster or a door lock, and if you know any details on the communications protocols (which ones)? Thus far, we only know it uses IP. That does not help at all, just about everything uses IP nowadays. This is also why my answer is so vague; I'd like to be more precise, but you do not provide enough information for me to do so.
I have a PHP Code, that uses a web service to query some data. However, this web service limits queries per second based on the server (i m not sure about the exact mechanism, but it seems to be the IP address)
I m using ajax to query this data from a PHP file on my server, but is there some way I can let my client search this data for themselves by faking that they are requesting the data rather than my servers?
The issue is I am getting a RateExceeded error message from server, as soon as two clients are requesting the same page, which is rather obvious since the webservice is only seeing one server, which is my server.
So, can I somehow, make it happen that when these clients query the data, the service is rather thinking that the request is being originated via these clients, rather than my server.
You can't really fake it, but if you could query the webservice directly via AJAX, it should be seeing the clients' IP addresses. Note that if you're doing any kind of processing on the data that the WS returns, you'd have to perform it in JavaScript, on the client side.
If the request from your server to the WS contains any confidential data (e.g. some kind of access key) which the clients must not see, this approach is useless.
Am not sure if what I am doing is absolutely correct. But here goes:
User logins into chat via web-based interface
User is informed of updates via Comet
User enters details which goto a PHP file which further connects to a Jabber server
Now the problem is that when the user wants to send a message, it's simple, run php in which i connect to jabber server and send the message. The problem arises when I am waiting for a message. Cause if I login and check messages and disconnect, on the other users end I will show up as disconnected.
Am I approaching this problem in a wrong way? Should I directly connect to the Jabber server (via javascript) instead of a PHP layer in between? How to recieve messages via PHP?
I haven't tried it out, but you might want to look at xmpphp. Secondly, you might want to consider keeping the user logged in to the XMPP server (aka a Jabber server) for as long as they're logged in to your website. You probably want to have a timeout of some kind in case they leave your website and don't come back.
As for whether or not you should connect via JavaScript, I don't see why you couldn't. I would suggest that you go for whatever seems the simplest to you. You might want to check out Strophe, which I hear good things about, for that case.
The only XMPP library that I've used extensively though is headstock, but that requires using python and Kamaelia.
this is an inherent problem (or feature) with http - there are no lasting connections (not really). you need a workaround, there is no real solution.
you could do it with java or flash, but that's not really nice (javascript 4tw!).
the other possibility would be to create an intermediate client what translates connections between the browser and the webserver to connections between the webserver and the jabber server. messy, but possible.
or maybe there is an API that helps with this.
directly connecting to the jabber server via javascript
i possibly slept through the latest ajax-inventions, but afaik you can only communicate with the host the source-html file comes from (ignoring greasmonkey and addons). no different domains, no different ports, period. unless you're going to teach your jabber server how to serve your chatpage-html to the browser, this will get problematic. moreover, staying connected doesn't even work, because that would require multipart-responses. those are only supported by mozilla, and this is why the ugly duckling COMET even exists in the first place. comet itself is a workaround to avoid the inability to hold connections while transfering data.
So the issue, as far as I can tell, is that when the Jabber user on the other end responds. The problem there, at least in part, is that the user is responding to another user on the Jabber server, yet you want the php script to be aware that this response has taken place without holding the connection open (which makes sense since the script is no longer running, probably).
One option, albeit a really silly one, is:
Have a php script that can broker a connection to the Jabber server for both sending and receiving for the user on your page,
Use AJAX to send messages for the user (the AJAX would point to the above script, the script would send the message.)
Have a Javascript infinite loop that pings the same script ever 10 seconds or so, checking in to see if there are messages. If there are, they get passed back to the client and output to the user.
There are only two issues with the above:
1) If the user isn't connected when the message is transmitted, will the php script still see/get the message?
2) A client side loop that makes ajax requests every 3 seconds would probably be a huge drain.
Solution 2:
OpenFire jabber server. It comes with a web chat client built in, and it has an addon called Fastpath, which is meant to handle HTML-based chats on the client end (like the "chat with an agent now!" feature on too many support pages.)
We use this at work and it is very customizable, can be integrated with other scripts (for instance, if you want a script that fills in the user details from their login, or adds some custom avatar, or whatever), and it (OpenFire) has tons of other extensions and addons that, if this isn't what you want, they probably have what you are looking for.