From: Peter Olcott on

"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.
>
>
> --
> HLS

This might work:
(1) I make my own little web server (or adapt one of the
CodeProject Ones)
http://www.codeproject.com/KB/IP/webem.aspx
(2) My OCR code is a running process that gets its requests
via IPC from the Mini webserver.
(3) The OCR code passes its results back to the Mini
webserver via IPC.
(4) The Mini webserver is another separate process that runs
continually.


From: Hector Santos on
Peter Olcott wrote:

>
> This might work:
> (1) I make my own little web server (or adapt one of the
> CodeProject Ones)
> http://www.codeproject.com/KB/IP/webem.aspx
> (2) My OCR code is a running process that gets its requests
> via IPC from the Mini webserver.
> (3) The OCR code passes its results back to the Mini
> webserver via IPC.
> (4) The Mini webserver is another separate process that runs
> continually.

Not might, will. Standard technology, practice and methods for high
end application servers. Step 2 and 3 would be:

- an embedded script language, p-code or otherwise or
- a script map (CGI) external spawn

They will communicate with your OCR server.

--
HLS
From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:unGG%23UfxKHA.3408(a)TK2MSFTNGP06.phx.gbl...
> Peter Olcott wrote:
>
>>
>> This might work:
>> (1) I make my own little web server (or adapt one of the
>> CodeProject Ones)
>> http://www.codeproject.com/KB/IP/webem.aspx
>> (2) My OCR code is a running process that gets its
>> requests via IPC from the Mini webserver.
>> (3) The OCR code passes its results back to the Mini
>> webserver via IPC.
>> (4) The Mini webserver is another separate process that
>> runs continually.
>
> Not might, will. Standard technology, practice and
> methods for high end application servers. Step 2 and 3
> would be:
>
> - an embedded script language, p-code or otherwise or
> - a script map (CGI) external spawn
>
> They will communicate with your OCR server.
>
> --
> HLS

It looks like the mongoose approach may be simpler:
http://code.google.com/p/mongoose/wiki/EmbeddingMongoose

Simply bind the webserver and the application into a single
executable that now has web server capability.
It has HTTPS too, the only other thing that I need is
cookies. I don't know if it has cookies.

Do you know a way that I can authenticate once, and then
have several (possibly many) ten cent financial transactions
that decrement the account balance very quickly? Since HTTP
is a stateless protocol, I was wondering how I could best
maintain this state. Could I use a cookie for this?


From: Joseph M. Newcomer on
See below...
On Tue, 16 Mar 2010 21:06:35 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
>news:eyHxkRXxKHA.2644(a)TK2MSFTNGP04.phx.gbl...
>> Peter Olcott wrote:
>>
>>>
>>> That is not simple enough for my users. I want a browse
>>> button on a webpage that browses the local hard-drive.
>>
>>
>> <INPUT type="File" name="filename" />
>>
>>> It seems that the only completely portable way to do this
>>> is HTML and this HTML is hooked up to CGI. Maybe I could
>>> build something from scratch at the other end to handle
>>> the input. I would guess that this would not provide any
>>> improvement over C++ FastCGI, and cost more development
>>> time.
>>> I am leaning toward Linux now, so a Microsoft thing
>>> ported to Linux may not be as good as a native Linux
>>> thing.
>>
>> Geez, you ain't going to get nothing done with this lost
>> focus on "FastCGI".
>>
>> Once again, all you need is a standard C/C++ console
>> application that reads standard input to read your HTTP
>> transfer encoded data block. You either write the
>> multi-part MIME processor or you get a library or class
>> that does it for you.
>
>What handles transmission errors? Another thing, I want to
>immediately close the connection on the first packet if
>anything besides a 24-bit PNG file is detected. My app MUST
>be written in C++. I was envisioning this as a single app.
>One that handles the URL-encoded input, and the same one to
>process this data. In any case the one that processes this
>data must remain resident.
****
You clearly missed any comprehsension of TCP/IP. TCP/IP is as reliable as a piece of wire
between the two sites, and that essentially means it is 100% utterly reliable, or it has
failed completely and there is no recovery (read about how TCP/IP retransmission works!)
so there are *no* "transmission errors" at all, or you will get a notification that the
protocol has failed utterly and there is NO recovery from that, so browsers deal with it!
I have no idea what you are talking about when you talk about "clos[ing] the connection on
the first packet" since, among other things, packets are invisible at the application
level and you NEVER see them, you may or may not get all the bits you want in one Receive
(it is a STREAM transmission, and therefore you simply CANNOT tell where packet boundaries
are or anything else, and MUST assume that it will take 2 or more Receives to get what you
need, and you have not identified what you mean by a "24-bit PNG file is detected". You
must be living in an alternate plane of existence wheere there is some magic that
determines that because some magical bits appear at the front of a byte sequence that the
rest of the sequence must necessarily conform to that purported reality, and that in spite
of the fact that TCP/IP *guarantees* delivery of bits intact that you might accidentally
see the wrong bits after the client makes a transmission (this will never happen; TCP/IP
doesn't even allow for it!) which goes back to the advice I gave weeks ago, about reading
an introductory text on how TCP/IP actually works. There will be no "transmission errors"
that garbage the message; either the message is received correctly or a fake message has
been sent, and if you have a fake message, you close the connection and that's the end of
it. You go back and wait for the next connection. If you were using PHP and mime, you
would reject the data if it were not the correct mime image, or, having read it, the
conversion to an image encountered a problem. It would not be a transmission error; it
would be the result of erroneous data having been sent, because you will receive
everything that was sent, perfectly, or you will be notified that there has been an
unrecoverable network error (as will the transmission side). This is inherent in the
TCP/IP protocol.

So forget the concept of "first packet" or even "packets". They are nonsense at the
TCP/IP application level. There is one, and only one, reality: the byte sequence. If you
continue to believe in inappropriate (and erroneous) concepts like "packets" when using
TCP/IP, you are DOOMED! They only have a reality at the lowest levels of the protocol,
and at the application level, they have been erased entirely from your awareness. People
who believe in anything other than the byte stream eventually have problems.

And please abandon your concepts of "resident", since you have demonstrated beyond any
possible doubt that you simply do not understand how operating systems work. You have
these strange wishful-thinking models that have no realization in any form of reality most
of us are familiar with, and you assume that operating systems work in accordance to your
dreams and not the way they are actually implemented.
****
>
>>
>> If you write a PHP script, it will do it for you. You can
>> put this under a FASTCGI PHP setup under a certain port
>> and then write a HTTP client do do your testing.
>>
>> However, I don't believe PHP naturally supports memory
>> maps unless you find a public PHP class to expose the
>> WIN32 memory map functions.
>>
>> The WIN32 API has all the memory mapping functions and you
>> will need this to handle the 4GB file.
>>
>> Now, on the wienie side, I don't know what it offers for
>> memory mapping. But I am sure it has something equivalent.
>>
>> --
>> HLS
>
>I have no idea what you are talking about when referring to
>a memory map. It is not a 4.0 GB file, it is numerous files
>making up a total of 4.0 GB.
****
Note that you cannot read a 4GB file into any WIndows app, since you only have 2GB (or
perhaps 3GB) of address space to use, and not all of that is available (your code, your
heap, and your stack, or each thread's stack, occupy the same address space). Therefore,
you will HAVE to use a memory-mapped file if you wish to access more data than you can
read. He is only pointing out the only possible implementation that will let you access
4GB of data effiiciently. If you think you can access 4GB of data, you can't even do that
in a Win32 app running in Win64 (which has a 4GB address space, but not all of it can be
used for your data! See previous comment). If you can currently read it all in, then you
don't have 4GB.
joe

>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on
See below...
On Tue, 16 Mar 2010 22:22:30 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote:

>
>Peter Olcott wrote:
>
>>> Once again, all you need is a standard C/C++ console
>>> application that reads standard input to read your HTTP
>>> transfer encoded data block. You either write the
>>> multi-part MIME processor or you get a library or class
>>> that does it for you.
>>
>> What handles transmission errors?
>
>
>Socket drop events/detection. You have to be ready for it.
****
Any On... notification of CAsyncSocket has an error code
*****
>
>> Another thing, I want to
>> immediately close the connection on the first packet if
>> anything besides a 24-bit PNG file is detected.
>
>
> shutdown(mySocketHandle,2)
> flush receiver buffer loop
> closesocket(mySocketHandle)
*****
I take exception with his "first packet" concept; it shows he is totally clueless about
TCP/IP protocol, which is *strictly* a stream protocol. I have no idea why he would think
that "packet" is a relevant concept. I just answered this in detail.
****
>
>> My app MUST
>> be written in C++. I was envisioning this as a single app.
>> One that handles the URL-encoded input, and the same one to
>> process this data. In any case the one that processes this
>> data must remain resident.
>
>
>What web server are you going to be using?
****
It probably doesn't matter if he builds an appropriate FASTCGI interface for it. And it
has to be in pure C++, not MFC, and it must not have a GUI.
****
>
>> I have no idea what you are talking about when referring to
>> a memory map.
>
>
>Well you should be aware of these things around here. Other common
>terms are Memory Map File (MMF) or File Map
>
>http://en.wikipedia.org/wiki/Memory-mapped_file
>http://msdn.microsoft.com/en-us/library/aa366556(VS.85).aspx
>http://msdn.microsoft.com/en-us/library/ms810613.aspx
>
> > It is not a 4.0 GB file, it is numerous files
>
>> making up a total of 4.0 GB.
>
>
>So you open each one up as a MMF. If this is static meta data, then
>merged them into one.
*****
He doesn't seem to grasp the fact that he only has 2GB (optimistically, 1GB) of contiguous
virtual memory into which something can be mapped. Probably a lot less. He mistakes a
32-bit address space *capability* for a 32-bit address space *reality*, a notion I have
tried to explain to him many times in the past as being wishful thinking, even if running
a Win32 app marked /LARGEADDRESSAWARE on Win64 wherer there really is 4GB-128K of total
virtual address space available. I guess his code, stack, and heap must all take 0 bytes.
And there is no threading, so no thread stacks are required.
joe
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm