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 07:58 Peter Olcott wrote: > 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. You miss understood how "MultiPlexing" was erroneously used in the WIKI. What you are describing is a PAD concept (Packet Assembler/Dissembler) as in a X.25 network. That is not the same. What the stupid fastcgi wiki description was trying to explain is how a standard Listening Server framework is designed. In a multi-threaded ready OS: - One or more Listening Threads, this accepts connections - For each connections, a new worker thread is started or reactivated from a pool of worker threads. Windows has its set of technology to optimized and scale this, see I/O Completion Ports, but thats just a wrapper for a standard listening server/worker thread framework. In other non-multi-threaded ready OS; you have one listening process EXE that will activate/start a PROCESS for each connection. That is what the WIKI is saying, that it will be listening for connections and as they come in, it spawns an autonomous thread or process (service handler) for the connection, then go back to listening. All servers do this. If you need a controlling concept for the order of connections and what data it is sending, than you got a "PAD" like concept. I seriously doubt that is what you are looking for. -- HLS
From: Peter Olcott on 17 Mar 2010 10:57 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:%23O%23c73YxKHA.5936(a)TK2MSFTNGP04.phx.gbl... > 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 You said a lot there. It was quite an overview. Of all of this that you said what kind of thing is required such that my OCR process would already be running with its set of DFA files already loaded into its std::vectors? CGI says that it loads once per request, which is find if it is only processing the HTTP, and then invoking an already running process. How do I organize it so that my process is ALWAYS already running? Also what kind of thing is required to piece together multiple simultaneous HTTP requests/posts?
From: Peter Olcott on 17 Mar 2010 11:00 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:eM1YZ9YxKHA.6020(a)TK2MSFTNGP06.phx.gbl... > 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: URL-encoded name value pairs. > > 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 11:17 Peter Olcott wrote: >>> (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. > > URL-encoded name value pairs. The client sends it on the GET line for the HTTP request header block or for a POST in the HTTP request body block. Once the web server gets it, for GGI, that will be part of the environment strings (QUERY_STRING) if its a GET request, and for POST, it would be part of the stdin and depending on the WEB SERVER, also made part of the QUERY_STRING. The ones here listed in the RFC are either required or optional. AUTH_TYPE CONTENT_LENGTH CONTENT_TYPE GATEWAY_INTERFACE PATH_INFO PATH_TRANSLATED QUERY_STRING REMOTE_ADDR REMOTE_HOST REMOTE_IDENT REMOTE_USER REQUEST_METHOD SCRIPT_NAME SERVER_NAME SERVER_PORT SERVER_PROTOCOL SERVER_SOFTWARE -- HLS
From: Peter Olcott on 17 Mar 2010 11:31
"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:uf7jxXZxKHA.3896(a)TK2MSFTNGP02.phx.gbl... > 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. Great now I know where to look. > > > -- > HLS |