Page 1 of 2
Interactions and choosing the right language
Posted: Thu Feb 23, 2006 10:32 am
by fangorn
feyd | This thread was split from here.
So guys, this sparked my interest because I have used PHP for several years now and written many systems using databases and the like. I love PHP! But I now have a reason to collect data from a hardware device (need to show on the web). I used the socket functions and I'm communicating to my hardware device - works beautifully. But my management is asking for different kinds of graphical outputs which are common in a windows based world (analog/digital gauges and such).
My question is - is this an area where PHP would have to hand off to another technology such as Java? Is the GD extension a viable option for GUI type displays? Is C# a viable contender to Java in that regard?
Posted: Thu Feb 23, 2006 10:44 am
by feyd
Anything that is time critical, PHP falls on it's butt. If the hardware is Java compatible, that may be a route to take, however I'm not a personal fan of it. So I might tend to swing the C/C++/C# routes. If you don't need to deal with cross-platform use of the applications, C# can be a nice choice.
Since this is fairly divergent, I'm going to split this off into a thread of it's own.
Re: Interactions and choosing the right language
Posted: Thu Feb 23, 2006 12:30 pm
by Christopher
fangorn wrote:I used the socket functions and I'm communicating to my hardware device - works beautifully.
Excellent, so the backend connection is working ... now the question is: can you also get a web interface with all the rapid development and ease of deployment benefits that it provides.
fangorn wrote:But my management is asking for different kinds of graphical outputs which are common in a windows based world (analog/digital gauges and such).
The first question I have is: Is this an IntERnet or IntRAnet. The reason I ask is because I recently saw a project that used SVG to render its graphics rather than GD and it was pretty amazing how fast the thing was. But only the latest browsers support it so you might require a plugin. I would say your main options are:
- ImageMagik/GD to create images on the server
- Generate flash using ming
- Generate SVG which is just XML
- Maybe try some of the Javascript drawing code around
Posted: Thu Feb 23, 2006 8:44 pm
by fangorn
feyd, stop me if I get off track here....
Yes, the tcp connection works well. The hardware is C++ on VXWorks. This is intranet for now. I picked PHP because of the internet requirement and my time constraint, but I will probably have time to go back and "do it right" in the future. So I've got 1 browser window with a tcp stream to the hardware and any time new data comes in it updates a main window via Javascript with the new data points.
Let me quickly describe what I'm supposed to do and maybe you guys can solidify some of my questions. I think this still holds to the PHP - Theory and Design topic.
I'm new on this project so here's what they got. The server is in C++ and communicates to a C++ client interface. Works well. But now they want to be able to be anywhere in the world and still communicate to the hardware. The hardware will be at various customer sites.
If I put the client on the web the obvious problem is that I cannot connect to a customer's network for security reasons. The more I think about this I don't think PHP is the way to go because of this "customer site" requirement.
My idea was to have the client and the server connect to our public web site and use it as a bridge and pass the info from one socket to the other. This is obviously not something that PHP is suited for.
But what's the best solution? Java, C++, C#? Of those, I've only done C++. So in my limited knowledge, I think that all 3 would work. But not PHP. Do you concur?
Feyd, you mentioned C# - why C# over C++? Just asking, need to learn...
Posted: Thu Feb 23, 2006 9:13 pm
by Christopher
I need a few points of clarification
fangorn wrote:But now they want to be able to be anywhere in the world and still communicate to the hardware. The hardware will be at various customer sites.
What does "still communicate to the hardware" mean? Is it two way communication? Is it hardware at the customer's site communicating back to your office?
fangorn wrote:If I put the client on the web the obvious problem is that I cannot connect to a customer's network for security reasons.
I am not sure what "on the web" means. If there is to be communication between two places then there has to be some kind of connection. Whether it is HTTP over that connection is a secondary decision.
fangorn wrote:"]My idea was to have the client and the server connect to our public web site and use it as a bridge and pass the info from one socket to the other. This is obviously not something that PHP is suited for.
When you say "our public web site" you mean a server I assume? PHP is good for displaying the data, which is one part of the system.
fangorn wrote:But what's the best solution? Java, C++, C#? Of those, I've only done C++. So in my limited knowledge, I think that all 3 would work. But not PHP. Do you concur?
If the system is in C++ then I might keep everything on the communications layer in C++ for maintainance reasons. But you can still us PHP to put a browser interface on it (which is what it is good for).
Posted: Thu Feb 23, 2006 9:29 pm
by feyd
fangorn wrote:Feyd, you mentioned C# - why C# over C ? Just asking, need to learn...
Similar to PHP, C# can get a skeleton application up quite quickly once you have the basics. For example, back at a company I worked at we wrote a tool in it inside of two weeks that built our animation files for us. Anyways, the reason I offered it was because from your initial post it sounded like they wanted an application that wasn't inside a browser and didn't require a server of some kind to do the communication for them.
Now, you could link PHP into an application and have it run the network layer or various other functions, but on the whole, that seems a bit overkill and, as arborint says, some maintainence issues may arrise.
I think, like arborint, that because the existing systems are written in C , it may be a good idea to keep them there. But I still can't say for sure as I would like to see arborint's questions' answers.
Posted: Thu Feb 23, 2006 9:35 pm
by fangorn
I think we're on the same page arborint, but I'll clarify.
Essentially, we want a remote interface to the hardware. The 2 pieces of software (the hardware's software and the client's software) will be remote from each other. Yes, it is 2 way communication. No, the communication is not back to our office. The communication is from 1 software on 1 network to another module of software on another network.
What I meant by "on the web" is the idea of having the interface being on a web site so that the end user doesn't have to install anything on their computer. I'd love for monitoring to occur by 1 user coming to our web site to see the data.
I've always used PHP to show data from a database to the browser. And yes, I understand that PHP is good for that, but this is more real time. So it sounds like what Feyd was saying is that PHP would not be good for a real time system.
So, where does C# come into play? When would you choose C# over C++? And what's a good legitimate use of the socket functions in PHP?
Posted: Thu Feb 23, 2006 9:57 pm
by feyd
C# is, to me, roughly where C was heading on its path to D, the next step beyond. C# is a combination of C , Java, and Delphi. It is very object oriented, but not as heavy handed as Java. It offers native 64 and 128 bit numeric formats, allowing extension of the compiler and most core objects. From what I remember it has networking already available, internally, so no extra libraries to get and try to work. The only problem is it's not so portable. True, there is the Mono project, and it is coming along. However, if portability is more important, Java or Delphi may be more of interest.
Since you want to have interaction with this on a website, I may swing toward doing it PHP, with maybe an Ajax component, but to me, a lot of browser communication is fairly heavy when you're more needing timely, simple packets. Must each transmission end up in order? If so, TCP transmissions are pretty much the only thing (readily available.) Otherwise, UDP is available. UDP has smaller fixed packet sizes than TCP and doesn't require reaching the destination in the same order it was sent. Either way, PHP can handle it. The problem still comes to the browser getting updates from the PHP server. These transmissions will happen over TCP, so some delays can easily happen. Reducing packet sizes and grouping packets together into a single pool may help improve perceived performance.
Posted: Fri Feb 24, 2006 4:06 am
by Christopher
Not quite on the same page yet.
fangorn wrote:Essentially, we want a remote interface to the hardware.
When you say "we" do you mean your company from your server, or that you want it for your customers to monitor their hardware?
fangorn wrote:The 2 pieces of software (the hardware's software and the client's software) will be remote from each other. Yes, it is 2 way communication. No, the communication is not back to our office. The communication is from 1 software on 1 network to another module of software on another network.
OK, so when you say "2 way" that means that the interface receives data from the hardware and that interface also sends commands that control the hardware? When you say the communication is from "1 software on 1 network to another module of software on another network" do you mean that the hardware and the monitoring/controlling computer are on different networks? Are these networks connected by a router or both connected to the Internet?
fangorn wrote:What I meant by "on the web" is the idea of having the interface being on a web site so that the end user doesn't have to install anything on their computer. I'd love for monitoring to occur by 1 user coming to our web site to see the data.
This confused me a little because above you said "the communication is not back to our office" but here you imply that you would like it to be back to your office
Posted: Fri Feb 24, 2006 6:56 am
by fangorn
Alright, sorry man. I was trying to be succinct. There's 2 things happening. A demo for concept purposes and a possible real product. The demo I've done with a PHP script asking for data from the hardware. This works for the demo because both the web server where the PHP script resides and the hardware are inside my company's network. The possible real product will have the hardware and the remote interface being separated on different company's networks but both connected to the Internet. So my initial thought was that I could just write a pass through server application that resides on a public web server (since both devices would be able to get to that server) and just pass the data through. But then I thought there might be a way that the end user (the interface) could simply go to some URL and see the data on a web site instead of loading some software on their machine. You're probably thinking "well why don't you store the data and then PHP is just pulling it out of a database and showing the data". I'm trying to push for that concept since another feature my boss wants is to store the data as well. It seems logical doesn't it that if you have this data you want to look at then why not store it as well for future use. But I'm having to convince him of that for some reason.
When I say "we" ... My company is trying to prove to our customer (Uncle Sam) that this remote monitoring is possible on this custom hardware.
2 way - the guy who writes the embedded software on the hardware designed this port request method so that the client asks on a base port for a port to listen on and the embedded software starts a thread to handle that new port and the data going out on it. So right now, it's 2 way. The client (PHP or otherwise) has to request a port and then it just sits there polling for data on that port. I've since found out that they don't want multiple clients, so this scheme seems overkill. So I think it could easily be changed to 1 way communication.
This is by now probably way off track from where we started and I'm sorry for that. I appreciate the discussion though. See, the guys that I work with have this neat concept of a system, but the first thing they told me was that they had this client that connected TCP to this embedded server but they weren't sure if TCP would travel on the internet...are you laughing like I did?
Feyd, thanks for the explanations. I'm just trying to get my hands around C# and why I would possibly use it. I haven't used an Ajax component either. These packets are pretty small actually - about 500 bytes. So when would you use C# instead of PHP? I always thought of PHP as the open source counterpart to ASP. So how does C# fit in with ASP? If the answer is that C# is more like Java then I understand.
Posted: Fri Feb 24, 2006 7:53 am
by Buddha443556
Not sure weather
LabVIEW by National Instruments qualifies as a language, it's described as a "Graphical Development" system. However, it's specifically for test, measurement and control applications. Uncle Sam might have more confidence in such an implementation too. However, it's not cheap and a hell of a learning curve. Think they're had web-base interface since version 6 something. Just another option to look into.
Posted: Fri Feb 24, 2006 11:09 am
by feyd
The more the interface client needs to directly communicate with the hardware, the more I'd push toward a non browser application. With a browser based on, you'd be playing telephone, causing delays in feedback from both ends, which likely isn't helpful. Now, whether that means C# or Java or Delphi, it's up to you, your company and Uncle Sam.
I'm surprised they (the government) are even considering something written in C.
As far as ASP - C# vs Java - C#, it has nothing to do with ASP. It can be used in ASP.NET set ups, but any .Net language can do that. It's much more like Java in that context. It shares a lot of concepts with Delphi, some various things from Java, and a good amound of C/C++ styling. But is far more flexible from my experience. The only real problem, besides platform support, is the builds are generally quite large. So if they wanted this on, say a PDA, it's a bit harder to do. Not impossible, from what I know, but a bit harder. You may end up having to write several clients in various languages.. a possible nightmare.
Posted: Fri Feb 24, 2006 1:24 pm
by fangorn
Thanks guys, this conversation really helped me put my disjointed knowledge into perspective.
So I still want to know - what is a good reason to implement a PHP script which utilizes the socket capability?
Feyd, have you used that feature of PHP for anything?
Posted: Fri Feb 24, 2006 1:34 pm
by Christopher
fangorn, from reading your description it seem like you should really implement a couple of separate systems. The first is the communication part between the "hardware' and whatever remote system is receiving the data. For that my main concern would be security, but it should be too difficult to do.
The second part is whatever is going to run the "receiver" and gather data. The "receiver" should be interface independent. It's like a socket that you can get data from. For example you might want a "presenter" that polls the device on demand or at preset intervals. Or you might want an "archiver" that gathers the data and saves it in a database -- then the presentation code would access the database, not the "receiver."
A further question I would have is about buffering. Does the "hardware" maintain a buffer of its output so the "receiver" can poll at longer intervals? Does the "receiver" buffer the data it receives so it could run on a cron and then have the "archiver" or "presenter" get the data saved at longer intervals?
Posted: Fri Feb 24, 2006 1:53 pm
by feyd
I have used sockets for various things, but mostly as a toy or mocking up something. For instance, creating a "dirty" server of sorts for varying information to see if an idea would work. Once I figure that out, I go and build the real thing.