How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Hector Santos on 17 Mar 2010 00:54 Peter Olcott wrote: >> Is this an ACTIVEX, FLASH or JAVA client side file upload >> component? > > It is an HTML web page, BrowseFile widget. What BrowseFile Widget? When you say "widget" to me, you are talking about something extra that is installed. >> Whats wrong with just using standard HTML INPUT >> type="file" control with a HTTP upload to a basic HTTP >> server? > > That is what I am using. See what I mean. That is not a "Widget" that is that the standard HTTP file upload idea. The browser has their own way for displaying a browser file selection window. I guess that might be called a "widget" in the technical sense. >> Now, when you using any advanced method other than HTTP, >> you can define your own communication I/O with a >> persistent connection. >> >> In this case, it isn't FASTCGI - but a simple backend >> server. Call it want you want, it is still a backend >> server. > Maybe this is simpler, but it the HTML Button is already > sending the data in CGI format, wouldn't FastCGI be simpler? If you using the HTML File Upload Tag, that is not a "CGI format." Ok, this is what I mean. Look the flow is like this: BROWSER --> HTTP REQUEST ---> WEB BROWSER <-- HTTP RESPONSE <--- WEB To get AWAY from this, you need "Special Pluggins" that will connect on a different post and do communications. The HTTP File Upload is not one of these extra pluggins, it will use the standard HTTP protocol. It is only a "widget" in the sense that each browser will run a local Native GUI as the file selection browser. Most browsers will simply run an client side pluggin to run the WIN32 OpenDialog Functions. So, when you click SUBMIT, there is no CGI format here. It is here: WEB ---> "APPLET" The WEB will start a "Processor Applet" for the HTTP REQUEST. The APPLET can be: - Embedded (built into the server). Ours embedded, IIS/ASP is embeded - Non-Embedded, External Process - called SCRIPT MAPPING. There are two kinds of SCRIPT MAPPING: - EXE PROCESS, this generally has a /CGI/ or /CGI-BIN/ alias example: /yourdomain/cgi-bin/myOCR.EXE The web server as a backend configuration for the actual location of /cgi-bin/ alias. - EXTENSION BASED SCRIPT EXE PROCESSOR example: /yourdomain/myprojects/myOCR.PHP In BOTH cases, there are processed as a CGI process using CGI standards, such as the one identified in the IETF RFC 3875 http://www.ietf.org/rfc/rfc3875 the different is that as a SCRIPT map, the MyOCR.PHP is the name of the script passed to the PHP-CGI.EXE process spawned by the web server. As a pure CGI, there is no script to pass. So the web server can spawn: Pure CGI: c:\protected-cgi-bin\myocr.exe Script Map Extension: c:\php525\php-cgi.exe c:\web-root\myprojects\myocr.php In both cases: WEB --> ENVIRONMENT TABLE --> CGI process Standard input (posted data) WEB <-- Standard output (HTML?) <-- CGI process So when you say "FASTCGI" you (THE WEB SERVICE) are basically setting up a 24x7 service pool that will take this information as it was a CGI. So when you speak of FASTCGI, you are either: 1) Creating a actual FASTCGI server that will do all the pooling, thread management, listening servers, spawning of threads, pretty much starting with the CSPServer codeproject code I sawed. 2) Creating a script, like in PHP that will run on a FASTCGI supported server with PHP-CGI.EXE. The server has to support this. The reason for #2 is because you want to create this as single thread and the SCRIPT CGI processor will run it for you as a single thread. What I am telling you is that you need to concentrate on the actual program that will: Read the CGI information (Environment Strings) Standard Input (posted data) regardless if its handled as a FASTCGI or not. It has nothing to do with FASTCGI per se. Now, if you had a special WIDGET that doesn't use HTTP, or could use HTTP, but it directly connected to the backend server, you really don't have a FASTCGI concept, but a client/server concept. If that is what you want, then you got your work cut out for you. -- HLS
From: Hector Santos on 17 Mar 2010 00:57 Peter Olcott wrote: > Not in the case of FastCGI, FastCGI does not use environment > variables. Thats not true. PHP-CGI.EXE -b FASTCGI mode read env strings. -- HLS
From: Hector Santos on 17 Mar 2010 01:04 Peter Olcott wrote: >> So again, what web server? > > I will probably be using some version of Apache because I > will probably be hosting this under one flavor of Linux or > another. > (1) My App must remain alive it can not terminate, it must > keep at least most of its data in memory, even if I have to > write another process to force this. Over Design is a symptom of knowing how things work. :) > (2) I will probably be using the HTML BrowseForFile button > as the user interface, thus the PNG file will be coming as > URL-encoded CGI format. No, it will not be coming in "CGI Format" (whatever that is), not if you are using a standard HTML <input type="file" /> tag. "CGI Format" could only possible mean two types on input: Environment Strings Standard Input. and one form of output Standard Output see the RFC 3875 and the OReilly CGI Programming guide on the web: http://oreilly.com/openbook/cgi/ FASTCGI doesn't change any of the above. -- HLS
From: Hector Santos on 17 Mar 2010 01:51 Peter Olcott wrote: >> In this case, it isn't FASTCGI - but a simple backend >> server. Call it want you want, it is still a backend >> server. > Maybe this is simpler, but it the HTML Button is already > sending the data in CGI format, wouldn't FastCGI be simpler? Peter to summarize this: 1) HTML/HTTP does not send "CGI Formats." 2) You would not be writing a FASTCGI server. You would be running a writing a process that would run as a CGI under a FASTCGI pool managed by the web server. 3) If you going to use Apache, you will be writing a PHP script as it only supports FASTCGI for PHP. Based on your comments, what you really want is very simple: Your own special WEB SERVER with the built-in code for your work. -- HLS
From: Peter Olcott on 17 Mar 2010 07:35
"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OJiTrWYxKHA.6140(a)TK2MSFTNGP05.phx.gbl... > Peter Olcott wrote: > > >> It seems to me that most of you guys continue to simply >> ignore some of my most fundamental design requirements. >> App load time for me can be several minutes, app >> execution time of a large job is never more than 100 >> milliseconds. > > > Thats because you didn't know about NT old technology > called Memory Mapped Files. > >> The web service needs no GUI. It is all PNG in, and UTF-8 >> out. > > > A web service is just a HTTP protocol processor. What it > does is based on the URI or specifically script-path: > > <scheme> "://" <server-name> ":" <server-port> > <script-path> <extra-path> "?" <query-string> > > But the I/O is the same across the board. > >> All that I know for sure is that some of my fundamental >> requirements are immutable. Some of Hector's advice >> seemed to continue to ignore these requirements. > > > Until you mentioned the 4GB I realized your layman > thinking why you believe FastCGI is your answer - it > isn't. You need to use Memory Mapped Files and until you > realized this everything else is a moot point. > >> I was envisioning the web service as a single >> application. This > > > may not have been the way that he was envisioning it. > > Of course I was because I know YOU were not be too > sophisticated but to do it any other way and this is why I > said your reasons for FASTCGI were not incorrect. > > When you say "FASTCGI", you are talking about a "service" > that the web server connects too. Not the client. I know > you won't be able to do it because short of using PHP, you > need to write a C/C++ client/server that does everything a > CGI application will do - standard I/O. > > Again I ask, what web server will be using? > > If you are will be writing your own WEB SERVER (HTTP > processor), you will be created a embedded solution - you > won't need FastCGI. I read some technical docs on FastCGI, and it reminded me that the client calls may have many packets that are coming from different sources and these packets may not be in the right order. Part of what FastCGI does is directly handling the multiplexing of this. Does your solution include this multiplexing? > > Now, as I mentioned, the old reason was slower machines > and process startups. That isn't the case today. Today, > FASTCGI is not as important and also most systems are > going to the alternative - embedded solutions. > > So again, what web server? > > PS: Please quote the mail better, no need to quote the > entire message for one or two lines. > > -- > HLS |