PDA

View Full Version : Back to the web server



N1LAF
11-23-2010, 09:41 AM
Programming a web server, you have to know a little bit about what to expect for incoming packets, and what to send back. My little web server is working, and thought to test with my iPod.

The text was freaking small, unreadable without magnification. There has to be a simpler way. Fortunately, there is, and it is quite simple to detect mobile phones and send back the appropriate DOCTYPE.

When the iPod sends a request for page, this is what is received:

GET / HTTP/1.1
Host: xxx.xxx.xxx.xxx
User-Agent: Mozilla/5.0 (iPod; U; CPU iPhone OS 3_1_3 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7E18 Safari/528.16
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive


I can parse out "Mobile" as well as "iPod, iPhone, etc.. to flag mobile device.

on the outgoing message, I select the appropriate DOCTYPE! for the MobileFlag:

HTTP/1.1 200 OK
Date: Tue, Nov 23, 2010 9:37:33 AM
Server: PAFserver3
Content-Type: text/html

<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN" "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
<html>
<head>
...

The text on the Safari browser on the iPod is easily readable.

Soon, I will open this server to the internet for testing, using an obscure port number. Those who are interested on this project, let me know. I would like to sample other mobile devices to make sure I have a good capture code on what is Mobile, and what isn't.

N1LAF
11-23-2010, 10:16 AM
Just FYI, a windows XP/Firefox request packet:

GET / HTTP/1.1
Host: xxx.xxx.xxx.xxx
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cache-Control: max-age=0

N2CHX
11-23-2010, 10:35 AM
I have a Droid. Let me know when you want me to hit the server with it.

n2ize
11-23-2010, 10:44 AM
Any reason you wrote your own web server instead of using Apache or the hundreds (or maybe thousands) of other scaleable and highly configurable ones out there ?

N1LAF
11-23-2010, 10:51 AM
Any reason you wrote your own web server instead of using Apache or the hundreds (or maybe thousands) of other scaleable and highly configurable ones out there ?

Because this will directly interact with programs I create. I can use a web browser to set parameters in my custom programs. Wait until I create a web interface for my radio, and do other cool stuff. It will be more than dishing out pages, and fully customizable.

N1LAF
11-23-2010, 10:51 AM
I have a Droid. Let me know when you want me to hit the server with it.

Droid would be cool! Almost there... need to set my router to pass requests.

N1LAF
11-23-2010, 11:36 AM
Droid works... identified and sent proper DOCTYPE!

NQ6U
11-23-2010, 11:38 AM
I use an iPhone, but that would be the same user agent as your iPod.

n2ize
11-23-2010, 04:36 PM
Because this will directly interact with programs I create. I can use a web browser to set parameters in my custom programs. Wait until I create a web interface for my radio, and do other cool stuff. It will be more than dishing out pages, and fully customizable.

But couldn't you take your existing web server and rebuild it ? For instance you can take Apache and you can create a module to do almost anything. You wouldn't even have to rebuild it everytime and it would handle almost anything you can think of.

N1LAF
11-23-2010, 04:57 PM
But couldn't you take your existing web server and rebuild it ? For instance you can take Apache and you can create a module to do almost anything. You wouldn't even have to rebuild it everytime and it would handle almost anything you can think of.

No, because I am using LabVIEW, and LabVIEW is it's own, distinct programming language. It is not text based.

kf0rt
11-23-2010, 05:31 PM
No, because I am using LabVIEW, and LabVIEW is it's own, distinct programming language. It is not text based.

Repeat after me, Paul:

"This is cool shit and not only am I having fun, I'm learning a bunch by doing it myself."

You owe the world no explanation beyond that which might enhance the world. And even that is optional. Sounds like some... well... cool shit! :)

n2ize
11-23-2010, 06:17 PM
No, because I am using LabVIEW, and LabVIEW is it's own, distinct programming language. It is not text based.

Why waste time with LabVIEW ? LabVIEW is junk. I wouldn't be caught dead with it on my system. There are a million other ways to program that are 100% better.

N1LAF
11-23-2010, 06:25 PM
Why waste time with LabVIEW ? LabVIEW is junk. I wouldn't be caught dead with it on my system. There are a million other ways to program that are 100% better.

Is this the arrogance of SW types? Met them before. LabVIEW is fun, easy, and 10x faster to create applications than C, and much faster than JAVA. What is your experience with LabVIEW?

n2ize
11-23-2010, 06:31 PM
Is this the arrogance of SW types? Met them before. LabVIEW is fun, easy, and 10x faster to create applications than C, and much faster than JAVA. What is your experience with LabVIEW?

My experience with LabVIEW was to eliminate it from my department. For simple one or two man projects it was okay. But for advanced cutting edge projects it was totally inflexible slow and inefficient. If you are working "within the box" it might be okay depending on what you are using it for.

N1LAF
11-23-2010, 06:41 PM
My experience with LabVIEW was to eliminate it from my department. For simple one or two man projects it was okay. But for advanced cutting edge projects it was totally inflexible slow and inefficient. If you are working "within the box" it might be okay depending on what you are using it for.

Will work just fine as a web server!
Efficiency is as good as the programmer...

NA4BH
11-23-2010, 06:46 PM
Will work just fine as a web server!
Efficiency is as good as the programmer...

OUCH !!!! It would even be funnier if I knew WTF you guy's are talking about.

NQ6U
11-23-2010, 06:53 PM
OUCH !!!! It would even be funnier if I knew WTF you guy's are talking about.

This:

http://4.bp.blogspot.com/_ppzKknN5F6M/TJK9NdFmGeI/AAAAAAAAABA/G0kp_-ai2V8/s1600/abacus-1-AJHD.jpg

n2ize
11-23-2010, 07:36 PM
Will work just fine as a web server!
Efficiency is as good as the programmer...

I'm just getting a little "ding" in there.. It depends what you are doing. LabVIEW is good for some things but not for others, It was designed with a purpose..

KC2UGV
11-23-2010, 08:10 PM
Will work just fine as a web server!
Efficiency is as good as the programmer...

You're writing a Web server in LABVEIW!!!

I really, really, really hope you are at least having fun, in that kinky, masochistic way :lol: Right on, though. Are you going to release it Open Source?

N1LAF
11-24-2010, 06:04 AM
You're writing a Web server in LABVEIW!!!

I really, really, really hope you are at least having fun, in that kinky, masochistic way :lol: Right on, though. Are you going to release it Open Source?

Thanks for the support, and it is meaningful from someone in your profession. Actually, a simple web server is easy, you have to understand what is happening during HTTP transfers, data structure, multitasking, etc. This revision to my previous start is a result of an observation while using wireshark, that there are multiple, simultaneous requests, so to be efficient, I moved from the READ-PROCESS-WRITE sequential to having a separate read loop and write loop, so I can take in multiple requests and process in parallel. This is done by using a "Request Queue" and a "Response Queue", as illustrated in the provided figure.

Note in the figure, I have three simultaneous, independent loops, Queue Incoming Connections, the Request Loop, and the Response Loop.

The Queue Incoming Connections captures outside requests and puts them into a Cx (Connection) queue. That is all what this procedure does.

The Request Loop dequeues the connection request, and reads incoming input, and then queue the requests.

The Response Loop takes incoming responses from previous requests, and sends them back out.

This is the complete communications portion of the program. Another procedure, independent of this "HTTPCORE" dequeues the requests, process the request, and enqueue the response to the Response queue.

I may merge the Request loop into the Queue Incoming Connections and eliminate the Cx Queue altogether, but this will depend on performance.

The HTTP Q is a control queue, and allows remote shutdown from the controlling part of the program. I will be able to drop this code into any LabVIEW application and allow remote operations and control using a web browser.

Note: the indicator "Sent" found in the Response Loop is used as a probe to ensure proper output, and will be deleted when finished. LabVIEW makes code troubleshooting very easy.

N1LAF
11-24-2010, 07:49 AM
Now rendering pages, graphics, etc..

BUT...

Have to deal with Microsoft file structure conversions - easy matter, just have to trap for %xx and change the / to \, etc, etc...

Done!

Next, display directory content if no index.html.....

Done!

Everything seems to work just fine. Brush up on some rough points, and this version will be finished!

Then will be the options, and CGI/Form handling (Corey, this will be the radio interface).