From: Joseph M. Newcomer on
We use a proprietary protocol, static IP address, and IANA-assigned port # for our
distributed network management app. The server binds the port # and waits for connection.
I then read the data from the network, parsing it for length and data components. The
proptocol is that the client sends a sequence of messages of the form
nnnn;dddddd....dddd

where nnnn is the length, in bytes, of the data, (by limiting it to 4 digits, we are
limited to a maximum message length 0f 9,999 bytes (most messages are < 128 bytes)
but I required 4 digits followed by a semicrolon or I simply disconnected. Then I read
that many bytes in as data and processed it. When the client was done, it sent
0000;
which was "End of data", which would cause the server to close the connection; the client
had already closed its side. In this scenario, the server never sent anything to the
client.
joe

On Sat, 13 Mar 2010 22:56:45 -0600, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>message news:qkmop5ddia2p14ci5jlv35vfu780nd2mag(a)4ax.com...
>> Typically, you would want to look at the HTTP protocol,
>> specifically, SEND and POST
>> requirements, as well as using an encoding such as
>> uuencode to encode your binary data.
>>
>> The typical question is how you want to integrate this
>> with a Web server such as IIS or
>> Aparche. THis would be port 80 (or 8080) protocolos.
>> Otherwise, you are free to obtain a
>> registered port number from IANA (www.iana.org, takes
>> about six weeks, no charge, fill in
>> a simple form), and you are free to send any message in
>> any format to that port #. It
>> does require that you have a static IP address so your
>> program can open a connection to
>> that IP address (obtain via the DNS server mechanisms,
>> e.g., if I had a static IP for
>> flounder.com you could request a DNS resolution of
>> flounder.com and find the one-and-only
>> IP address that represents it; note also that a static IP
>> address usually costs extra, and
>> I chose no to pay the price, so the IP address of
>> flounder.com changes every 24 hours).
>> joe
>
>I want to have two types of interfaces to my web service,
>one a simply web based GUI, and the other would be a machine
>to machine interface. I am not sure of the tradeoffs between
>all of the options. For example which would work better
>Sockets, SOAP or REST?
>I want to minimize overhead, server development costs and
>maximize ease of use. What approach would be easiest for
>client side programmers on possibly diverse platforms and
>languages?
>
>>
>> On Sat, 13 Mar 2010 17:58:02 -0600, "Peter Olcott"
>> <NoSpam(a)OCR4Screen.com> wrote:
>>
>>>I want to make a web service, and I don't need any complex
>>>protocol such as SOAP. I only need to take a stream of
>>>bytes
>>>representing a PNG image file as input, and provide UTF-8
>>>text as output.
>>>
>>>I might have a bunch of small nearly simultaneous
>>>requests.
>>>These can be processed in their order of arrival. A few of
>>>these requests may be multi-megabytes. Is socket
>>>programming
>>>a good way to go on this?
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
message news:uoftp55ehplnk6c7h9869qdfvb8o0fq3jj(a)4ax.com...
> See below...
> On Sat, 13 Mar 2010 23:02:30 -0600, "Peter Olcott"
> <NoSpam(a)OCR4Screen.com> wrote:
>
>>
>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>>message news:vbnop5dhutg9604v8dgsdpqge5ija6d20f(a)4ax.com...
>>> See below...
>>> On Sat, 13 Mar 2010 16:35:46 -0800, Geoff
>>> <geoff(a)invalid.invalid> wrote:
>>>
>>>>On Sat, 13 Mar 2010 17:58:02 -0600, "Peter Olcott"
>>>><NoSpam(a)OCR4Screen.com> wrote:
>>>>
>>>>>I want to make a web service, and I don't need any
>>>>>complex
>>>>>protocol such as SOAP. I only need to take a stream of
>>>>>bytes
>>>>>representing a PNG image file as input, and provide
>>>>>UTF-8
>>>>>text as output.
>>>>>
>>>>>I might have a bunch of small nearly simultaneous
>>>>>requests.
>>>>>These can be processed in their order of arrival. A few
>>>>>of
>>>>>these requests may be multi-megabytes. Is socket
>>>>>programming
>>>>>a good way to go on this?
>>>>>
>>>>
>>>>This sounds like more questions about your OCR
>>>>appliance.
>>>>
>>>>If the clients accessing your service are using the
>>>>Internet protocol
>>>>to access your server you do not need to ask this
>>>>question. You have
>>>>no choice.
>>>>
>>>>If you were coding on the Linux platform you would not
>>>>need to ask
>>>>this question, it would be automatically assumed that
>>>>you
>>>>are going to
>>>>use a sockets interface for your service. It would also
>>>>take about 30
>>>>minutes to code and debug a sockets interface and fork
>>>>logic to pass
>>>>this kind of data in and out of your OCR process.
>>> ****
>>> Actually, on the server side it is faster than this,
>>> because it is just a cgi gateway
>>> script; the data is sent up uuencoded or some other
>>> suitable encoding, and passed as data
>>> to the CGI-invoked program. Of course, you have to code
>>> up the CGI code, and that can
>>> take a while, but that's going to be fixed overhead no
>>> matter what means is used to encode
>>> the client data. But an HTTP POST with suitable
>>> encoding
>>> on the client side is all that
>>> is required, plus waiting for the HTTP response, both of
>>> which are (a) easy and (b) the
>>> same on Windows and linux.
>>> ****
>>
>>I want whatever code that handles servicing the clients to
>>be always memory resident. I didn't think that CGI worked
>>this way. I also thought that you need a separate CGI
>>instance for each client, I can't have that.
> ****
> Your assumption that this is possible is without
> foundation. While some servers try to
> simulate this, they do no guarantee it. WHat you want and
> what you are going to get seem

If my OCR code is not always memory resident then I can not
meet my performance requirements. If I am required to load a
separate instance of my OCR code to service every request,
then the system would utterly fail scalability. I can choose
the server and OS that this will run on.

> to be different. If you have unreleastic expectations,
> they cannot be met (note that this
> is what I was trying to tell you when you were insisting
> 500ms was mandatory...you are at
> the mercy of a huge numbe of variables, none of which are
> under your control and none of
> which are going to change just because of what you want.)
> joe

http://en.wikipedia.org/wiki/Common_Gateway_Interface
Are you saying that CGI is the ONLY underlying mechanism by
which remote webservices are invoked? The article above
mentions FastCGI surely I can find some server somewhere
that permits this.

> *****
>>
>>>>
>>>>Outside of your program, one could program a Perl cgi
>>>>script behind an
>>>>Apache based web server to copy the received data
>>>>streams
>>>>to files
>>>>with associated cookies or "handles" to the socket
>>>>sessions hosted by
>>>>the web server but you would have to process the files
>>>>and
>>>>respond to
>>>>them in such a manner that you could guarantee a reply
>>>>before the web
>>>>session expired. The script would handle the socket
>>>>sessions while
>>>>your process merely dealt with file I/O (pipes?) to the
>>>>scripts.
>>> ****
>>> Remember his original question about 500ms? This is
>>> part
>>> of the overhead that is "beyond
>>> the control of the program" that I kept referring to.
>>> In
>>> fact, the cgi invocation
>>> overhead is one of the performance bottlenecks of most
>>> Web
>>> servers,
>>
>>So I will have to use something else.
> ****
> You can do whatever you want; what you get is not under
> your control.
> joe
>
> ****
>>
>>> and Apache is probably
>>> the most efficient platform around for handling this (I
>>> haven't followed the latest round
>>> of tricks, only to note that it now has improved this
>>> time
>>> considerably)
>>> ****
>>>>
>>>>Even doing this in Windows with or without MFC, just
>>>>writing a simple
>>>>server, one could write a socket server that passed
>>>>files
>>>>to/from your
>>>>OCR program in a few hours.
>>>>
>>>>I hope you also realize that your OCR appliance could
>>>>probably very
>>>>easily be perverted to defeat web based captcha codes on
>>>>a
>>>>vast scale.
>>> ****
>>> I didn't want to mention this...but it seems pretty
>>> obvious. But we've always known that
>>> captcha codes were going to be short-lived...
>>>
>>> joe
>>> ****
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer(a)flounder.com
>>> Web: http://www.flounder.com
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>
> 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 Mon, 15 Mar 2010 21:45:50 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>message news:o6gtp51kbo2a10obpv7d44vbd2blj6qj8d(a)4ax.com...
>> We use a proprietary protocol, static IP address, and
>> IANA-assigned port # for our
>> distributed network management app. The server binds the
>> port # and waits for connection.
>> I then read the data from the network, parsing it for
>> length and data components. The
>> proptocol is that the client sends a sequence of messages
>> of the form
>> nnnn;dddddd....dddd
>>
>> where nnnn is the length, in bytes, of the data, (by
>> limiting it to 4 digits, we are
>> limited to a maximum message length 0f 9,999 bytes (most
>> messages are < 128 bytes)
>> but I required 4 digits followed by a semicrolon or I
>> simply disconnected. Then I read
>> that many bytes in as data and processed it. When the
>> client was done, it sent
>> 0000;
>> which was "End of data", which would cause the server to
>> close the connection; the client
>> had already closed its side. In this scenario, the server
>> never sent anything to the
>> client.
>> joe
>
>That sounds like a very clean and simple protocol. My input
>messages will be PNG files that can vary in size from < 1KB
>to over 2MB. My output message will be UTF-8 and will vary
>from < 1 KB to about 10 KB. I am guessing that working at
>the socket level would provide me the maximum flexibility
>for optimizing my aspect of the communication process.
****
You may be best off using some encoding technique, such as sending each byte as two hex
digits, e.g., if your data is 0x00 0xff 0x00 you would send the string (if you were using
my protocol)

0006;00ff00

and convert the nybbles back to hex upon receipt (generally, you want to try to avoid
sending strings with NUL characters embedded in them; life becomes a lot simpler if you
encode them as text).
****
>
>The case where I would like to achieve 500 MS response time
>will be one or two packets of input and one small packet of
>output. I know that the response time is mostly outside of
>my control, yet determining the stochastic distribution of
>response time with standard deviation would be feasible. I
>will probably wait for and do this empirical testing myself.
****
all you can do is turn the packet around as quickly as you can. Everything else is
outside your control.
****
>
>One good thing is that my web hosting provider has
>flexibility in the physical location(s) of the server(s). I
>would guess that closer would tend to mean fewer hops, and
>thus better response time.
****
You ill have to ask your provider if you can get a static IP, and note that the multiple
physical locations probably require multiple static IPs and there is no way to tell which
one is geographically closest to the client. Often ISPs do not want to divulge their
geography. Note also that your Web hosting service has to be prepared to run your
application (which can pose technical problems, for example, if they are Unix/linux based,
not all ISPs are willing to let "unknown" code run on their servers). So before you
undertake this approach, you need to confirm their requirements before you start building
the service. Note that getting a Windows service installed is yet another barrier if your
ISP is Windows-based. (Mine is linux-based). Also, you have to be able to suggest what
sort of load you will impose on their system, or you need to "lease" a dedicated server on
their site which runs the OS and programs of your choice. This is not cheap. This is why
CGI interfaces are considered more appropriate in many cases. So you need to find out
what services (and prices) your ISP offers.
joe
*****
>
>>
>> On Sat, 13 Mar 2010 22:56:45 -0600, "Peter Olcott"
>> <NoSpam(a)OCR4Screen.com> wrote:
>>
>>>
>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>>>message news:qkmop5ddia2p14ci5jlv35vfu780nd2mag(a)4ax.com...
>>>> Typically, you would want to look at the HTTP protocol,
>>>> specifically, SEND and POST
>>>> requirements, as well as using an encoding such as
>>>> uuencode to encode your binary data.
>>>>
>>>> The typical question is how you want to integrate this
>>>> with a Web server such as IIS or
>>>> Aparche. THis would be port 80 (or 8080) protocolos.
>>>> Otherwise, you are free to obtain a
>>>> registered port number from IANA (www.iana.org, takes
>>>> about six weeks, no charge, fill in
>>>> a simple form), and you are free to send any message in
>>>> any format to that port #. It
>>>> does require that you have a static IP address so your
>>>> program can open a connection to
>>>> that IP address (obtain via the DNS server mechanisms,
>>>> e.g., if I had a static IP for
>>>> flounder.com you could request a DNS resolution of
>>>> flounder.com and find the one-and-only
>>>> IP address that represents it; note also that a static
>>>> IP
>>>> address usually costs extra, and
>>>> I chose no to pay the price, so the IP address of
>>>> flounder.com changes every 24 hours).
>>>> joe
>>>
>>>I want to have two types of interfaces to my web service,
>>>one a simply web based GUI, and the other would be a
>>>machine
>>>to machine interface. I am not sure of the tradeoffs
>>>between
>>>all of the options. For example which would work better
>>>Sockets, SOAP or REST?
>>>I want to minimize overhead, server development costs and
>>>maximize ease of use. What approach would be easiest for
>>>client side programmers on possibly diverse platforms and
>>>languages?
>>>
>>>>
>>>> On Sat, 13 Mar 2010 17:58:02 -0600, "Peter Olcott"
>>>> <NoSpam(a)OCR4Screen.com> wrote:
>>>>
>>>>>I want to make a web service, and I don't need any
>>>>>complex
>>>>>protocol such as SOAP. I only need to take a stream of
>>>>>bytes
>>>>>representing a PNG image file as input, and provide
>>>>>UTF-8
>>>>>text as output.
>>>>>
>>>>>I might have a bunch of small nearly simultaneous
>>>>>requests.
>>>>>These can be processed in their order of arrival. A few
>>>>>of
>>>>>these requests may be multi-megabytes. Is socket
>>>>>programming
>>>>>a good way to go on this?
>>>>>
>>>> Joseph M. Newcomer [MVP]
>>>> email: newcomer(a)flounder.com
>>>> Web: http://www.flounder.com
>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
message news:s2fvp5lofrkboqmtma5ntrffb96j3a0200(a)4ax.com...
> See below...
> On Mon, 15 Mar 2010 21:45:50 -0500, "Peter Olcott"
> <NoSpam(a)OCR4Screen.com> wrote:
>
>>
>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>>message news:o6gtp51kbo2a10obpv7d44vbd2blj6qj8d(a)4ax.com...
>>> We use a proprietary protocol, static IP address, and
>>> IANA-assigned port # for our
>>> distributed network management app. The server binds
>>> the
>>> port # and waits for connection.
>>> I then read the data from the network, parsing it for
>>> length and data components. The
>>> proptocol is that the client sends a sequence of
>>> messages
>>> of the form
>>> nnnn;dddddd....dddd
>>>
>>> where nnnn is the length, in bytes, of the data, (by
>>> limiting it to 4 digits, we are
>>> limited to a maximum message length 0f 9,999 bytes (most
>>> messages are < 128 bytes)
>>> but I required 4 digits followed by a semicrolon or I
>>> simply disconnected. Then I read
>>> that many bytes in as data and processed it. When the
>>> client was done, it sent
>>> 0000;
>>> which was "End of data", which would cause the server to
>>> close the connection; the client
>>> had already closed its side. In this scenario, the
>>> server
>>> never sent anything to the
>>> client.
>>> joe
>>
>>That sounds like a very clean and simple protocol. My
>>input
>>messages will be PNG files that can vary in size from <
>>1KB
>>to over 2MB. My output message will be UTF-8 and will vary
>>from < 1 KB to about 10 KB. I am guessing that working at
>>the socket level would provide me the maximum flexibility
>>for optimizing my aspect of the communication process.
> ****
> You may be best off using some encoding technique, such as
> sending each byte as two hex
> digits, e.g., if your data is 0x00 0xff 0x00 you would
> send the string (if you were using
> my protocol)
>
> 0006;00ff00
>
> and convert the nybbles back to hex upon receipt
> (generally, you want to try to avoid
> sending strings with NUL characters embedded in them; life
> becomes a lot simpler if you
> encode them as text).
> ****
>>
>>The case where I would like to achieve 500 MS response
>>time
>>will be one or two packets of input and one small packet
>>of
>>output. I know that the response time is mostly outside of
>>my control, yet determining the stochastic distribution of
>>response time with standard deviation would be feasible. I
>>will probably wait for and do this empirical testing
>>myself.
> ****
> all you can do is turn the packet around as quickly as you
> can. Everything else is
> outside your control.
> ****
>>
>>One good thing is that my web hosting provider has
>>flexibility in the physical location(s) of the server(s).
>>I
>>would guess that closer would tend to mean fewer hops, and
>>thus better response time.
> ****
> You ill have to ask your provider if you can get a static
> IP, and note that the multiple
> physical locations probably require multiple static IPs
> and there is no way to tell which
> one is geographically closest to the client. Often ISPs
> do not want to divulge their
> geography. Note also that your Web hosting service has to
> be prepared to run your
> application (which can pose technical problems, for
> example, if they are Unix/linux based,
> not all ISPs are willing to let "unknown" code run on
> their servers). So before you
> undertake this approach, you need to confirm their
> requirements before you start building
> the service. Note that getting a Windows service
> installed is yet another barrier if your
> ISP is Windows-based. (Mine is linux-based). Also, you
> have to be able to suggest what
> sort of load you will impose on their system, or you need
> to "lease" a dedicated server on
> their site which runs the OS and programs of your choice.
> This is not cheap. This is why
> CGI interfaces are considered more appropriate in many
> cases. So you need to find out
> what services (and prices) your ISP offers.
> joe
> *****

Dedicated Linux server with 3.0 Ghz and 2.0 GB RAM, $56.00
per month a GoDaddy.com. Probably going to go with FastCGI.

>>
>>>
>>> On Sat, 13 Mar 2010 22:56:45 -0600, "Peter Olcott"
>>> <NoSpam(a)OCR4Screen.com> wrote:
>>>
>>>>
>>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>>>>message
>>>>news:qkmop5ddia2p14ci5jlv35vfu780nd2mag(a)4ax.com...
>>>>> Typically, you would want to look at the HTTP
>>>>> protocol,
>>>>> specifically, SEND and POST
>>>>> requirements, as well as using an encoding such as
>>>>> uuencode to encode your binary data.
>>>>>
>>>>> The typical question is how you want to integrate this
>>>>> with a Web server such as IIS or
>>>>> Aparche. THis would be port 80 (or 8080) protocolos.
>>>>> Otherwise, you are free to obtain a
>>>>> registered port number from IANA (www.iana.org, takes
>>>>> about six weeks, no charge, fill in
>>>>> a simple form), and you are free to send any message
>>>>> in
>>>>> any format to that port #. It
>>>>> does require that you have a static IP address so your
>>>>> program can open a connection to
>>>>> that IP address (obtain via the DNS server mechanisms,
>>>>> e.g., if I had a static IP for
>>>>> flounder.com you could request a DNS resolution of
>>>>> flounder.com and find the one-and-only
>>>>> IP address that represents it; note also that a static
>>>>> IP
>>>>> address usually costs extra, and
>>>>> I chose no to pay the price, so the IP address of
>>>>> flounder.com changes every 24 hours).
>>>>> joe
>>>>
>>>>I want to have two types of interfaces to my web
>>>>service,
>>>>one a simply web based GUI, and the other would be a
>>>>machine
>>>>to machine interface. I am not sure of the tradeoffs
>>>>between
>>>>all of the options. For example which would work better
>>>>Sockets, SOAP or REST?
>>>>I want to minimize overhead, server development costs
>>>>and
>>>>maximize ease of use. What approach would be easiest for
>>>>client side programmers on possibly diverse platforms
>>>>and
>>>>languages?
>>>>
>>>>>
>>>>> On Sat, 13 Mar 2010 17:58:02 -0600, "Peter Olcott"
>>>>> <NoSpam(a)OCR4Screen.com> wrote:
>>>>>
>>>>>>I want to make a web service, and I don't need any
>>>>>>complex
>>>>>>protocol such as SOAP. I only need to take a stream of
>>>>>>bytes
>>>>>>representing a PNG image file as input, and provide
>>>>>>UTF-8
>>>>>>text as output.
>>>>>>
>>>>>>I might have a bunch of small nearly simultaneous
>>>>>>requests.
>>>>>>These can be processed in their order of arrival. A
>>>>>>few
>>>>>>of
>>>>>>these requests may be multi-megabytes. Is socket
>>>>>>programming
>>>>>>a good way to go on this?
>>>>>>
>>>>> Joseph M. Newcomer [MVP]
>>>>> email: newcomer(a)flounder.com
>>>>> Web: http://www.flounder.com
>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>>
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer(a)flounder.com
>>> Web: http://www.flounder.com
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>
> 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 08:25:31 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>message news:uoftp55ehplnk6c7h9869qdfvb8o0fq3jj(a)4ax.com...
>> See below...
>> On Sat, 13 Mar 2010 23:02:30 -0600, "Peter Olcott"
>> <NoSpam(a)OCR4Screen.com> wrote:
>>
>>>
>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>>>message news:vbnop5dhutg9604v8dgsdpqge5ija6d20f(a)4ax.com...
>>>> See below...
>>>> On Sat, 13 Mar 2010 16:35:46 -0800, Geoff
>>>> <geoff(a)invalid.invalid> wrote:
>>>>
>>>>>On Sat, 13 Mar 2010 17:58:02 -0600, "Peter Olcott"
>>>>><NoSpam(a)OCR4Screen.com> wrote:
>>>>>
>>>>>>I want to make a web service, and I don't need any
>>>>>>complex
>>>>>>protocol such as SOAP. I only need to take a stream of
>>>>>>bytes
>>>>>>representing a PNG image file as input, and provide
>>>>>>UTF-8
>>>>>>text as output.
>>>>>>
>>>>>>I might have a bunch of small nearly simultaneous
>>>>>>requests.
>>>>>>These can be processed in their order of arrival. A few
>>>>>>of
>>>>>>these requests may be multi-megabytes. Is socket
>>>>>>programming
>>>>>>a good way to go on this?
>>>>>>
>>>>>
>>>>>This sounds like more questions about your OCR
>>>>>appliance.
>>>>>
>>>>>If the clients accessing your service are using the
>>>>>Internet protocol
>>>>>to access your server you do not need to ask this
>>>>>question. You have
>>>>>no choice.
>>>>>
>>>>>If you were coding on the Linux platform you would not
>>>>>need to ask
>>>>>this question, it would be automatically assumed that
>>>>>you
>>>>>are going to
>>>>>use a sockets interface for your service. It would also
>>>>>take about 30
>>>>>minutes to code and debug a sockets interface and fork
>>>>>logic to pass
>>>>>this kind of data in and out of your OCR process.
>>>> ****
>>>> Actually, on the server side it is faster than this,
>>>> because it is just a cgi gateway
>>>> script; the data is sent up uuencoded or some other
>>>> suitable encoding, and passed as data
>>>> to the CGI-invoked program. Of course, you have to code
>>>> up the CGI code, and that can
>>>> take a while, but that's going to be fixed overhead no
>>>> matter what means is used to encode
>>>> the client data. But an HTTP POST with suitable
>>>> encoding
>>>> on the client side is all that
>>>> is required, plus waiting for the HTTP response, both of
>>>> which are (a) easy and (b) the
>>>> same on Windows and linux.
>>>> ****
>>>
>>>I want whatever code that handles servicing the clients to
>>>be always memory resident. I didn't think that CGI worked
>>>this way. I also thought that you need a separate CGI
>>>instance for each client, I can't have that.
>> ****
>> Your assumption that this is possible is without
>> foundation. While some servers try to
>> simulate this, they do no guarantee it. WHat you want and
>> what you are going to get seem
>
>If my OCR code is not always memory resident then I can not
>meet my performance requirements. If I am required to load a
>separate instance of my OCR code to service every request,
>then the system would utterly fail scalability. I can choose
>the server and OS that this will run on.
****
And you manage this how? I sincerely hope you are not using VirtualLock because that has
an overall serious negative impact on total system peformance. So your need for a
dedicated server is an essential component here. And the way you would normally handle
this is as a system service which you communicate with. Whether or not the means of
communicating introduces delays is up to the Web hosting software; IIS and Apache have
different approaches to this problem, and I am an expert in neither (once, five years ago,
I configured an Apache server on Windows, but it was a long, painful process and I've
thankfully forgotten most of it)
joe

>
>> to be different. If you have unreleastic expectations,
>> they cannot be met (note that this
>> is what I was trying to tell you when you were insisting
>> 500ms was mandatory...you are at
>> the mercy of a huge numbe of variables, none of which are
>> under your control and none of
>> which are going to change just because of what you want.)
>> joe
>
> http://en.wikipedia.org/wiki/Common_Gateway_Interface
>Are you saying that CGI is the ONLY underlying mechanism by
>which remote webservices are invoked? The article above
>mentions FastCGI surely I can find some server somewhere
>that permits this.
>
>> *****
>>>
>>>>>
>>>>>Outside of your program, one could program a Perl cgi
>>>>>script behind an
>>>>>Apache based web server to copy the received data
>>>>>streams
>>>>>to files
>>>>>with associated cookies or "handles" to the socket
>>>>>sessions hosted by
>>>>>the web server but you would have to process the files
>>>>>and
>>>>>respond to
>>>>>them in such a manner that you could guarantee a reply
>>>>>before the web
>>>>>session expired. The script would handle the socket
>>>>>sessions while
>>>>>your process merely dealt with file I/O (pipes?) to the
>>>>>scripts.
>>>> ****
>>>> Remember his original question about 500ms? This is
>>>> part
>>>> of the overhead that is "beyond
>>>> the control of the program" that I kept referring to.
>>>> In
>>>> fact, the cgi invocation
>>>> overhead is one of the performance bottlenecks of most
>>>> Web
>>>> servers,
>>>
>>>So I will have to use something else.
>> ****
>> You can do whatever you want; what you get is not under
>> your control.
>> joe
>>
>> ****
>>>
>>>> and Apache is probably
>>>> the most efficient platform around for handling this (I
>>>> haven't followed the latest round
>>>> of tricks, only to note that it now has improved this
>>>> time
>>>> considerably)
>>>> ****
>>>>>
>>>>>Even doing this in Windows with or without MFC, just
>>>>>writing a simple
>>>>>server, one could write a socket server that passed
>>>>>files
>>>>>to/from your
>>>>>OCR program in a few hours.
>>>>>
>>>>>I hope you also realize that your OCR appliance could
>>>>>probably very
>>>>>easily be perverted to defeat web based captcha codes on
>>>>>a
>>>>>vast scale.
>>>> ****
>>>> I didn't want to mention this...but it seems pretty
>>>> obvious. But we've always known that
>>>> captcha codes were going to be short-lived...
>>>>
>>>> joe
>>>> ****
>>>> Joseph M. Newcomer [MVP]
>>>> email: newcomer(a)flounder.com
>>>> Web: http://www.flounder.com
>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm