How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Peter Olcott on 14 Mar 2010 00:24 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:%23syfmMzwKHA.4636(a)TK2MSFTNGP06.phx.gbl... > Peter Olcott wrote: > >> The other choices that I was envisioning were much higher >> levels of abstraction that hide all of the details of >> sockets. > > > Its called HTTP programming (if you are speaking web > service) > >> What about if my system is really busy and take ten >> minutes to begin processing, can I prevent the session >> from expiring? > > > Generally, no, as the browser can have its own timeouts. > > It can depend on the level of HTTP protocol, > > 1.0 is not persistent, a new socket connection for > each request. > > 1.0 is persistent, same socket connections can be > used. > > In the quest to move towards "interactive clients", some > browsers have special protocols to basically keep the line > active. > > But you can also do this with XHR (AJAX). > > Session Expiring can also depend on the web server you are > using. > > In general, the WEB is NOT an interactive process with the > backend. Its client/server. > > Web 1.0 - client/server, traditional, no javascript > > Web 2.0 - a little more of interactive operations > using > javascript which allows for XHR > > Web 3.0 - Web 2.0 with off-loaded clients, Flex, > SilverLight > Flash, etc. > >>> 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. > >> >> There is already a good replacement that I just >> encountered. Instead of asking me to type the word that I >> see, it asked me a question requiring a little >> intelligent human judgment.--->What color is an orange? > > > And why can't that be learned as well? > > The reasons for CAPTCHA are slowly disappearing with more > WEB 2.0+ directions. Its more of a fad and more and more > systems don't use it anymore. We have it only because > our silly customer THINK they ought to have it in their > SIGNUP forms. Don't need it for message posting because > users need to be logged in anyway. > > Only anonymous systems have a reason for it, and anonymous > systems have been rapidly disappearing for all sorts of > reasons. Anonymous Web is how the industry got its jump > start, it hurt systems like our own and others that > required logins - private by design where you don't need a > CAPTCHA. But today, nearly all systems require logins and > this has helped out business as I knew it would once the > early excitement was over. > > So personally, if this is for CAPTCHA, I don't see it as > worthy endeavor. This first level of this technology is for (among other things) machine to machine transfer of data where no other interface is available. www.OCR4Screen.com Niche market. The second level of this technology build from the first level + another invention + a whole object oriented computer language infrastructure makes a completely universal GUI scripting language that can be used for (among other things) the automated testing of any graphical user interface. This includes numerous graphical user interfaces that can not otherwise be automatically tested. www.GuiScripting.com Larger Niche market. The third level of the technology is built from the first two levels + another invention allows any set of complex graphical user interface operations to be intelligently repeated using a single keystroke or other event. www.SmartHotKeys.com Mainstream Market > > -- > HLS
From: Hector Santos on 14 Mar 2010 01:03 Peter Olcott wrote: >> >> So personally, if this is for CAPTCHA, I don't see it as >> worthy endeavor. > > This first level of this technology is for (among other > things) machine to machine transfer of data where no other > interface is available. > www.OCR4Screen.com Niche market. > > The second level of this technology build from the first > level + another invention + a whole object oriented computer > language infrastructure makes a completely universal GUI > scripting language that can be used for (among other things) > the automated testing of any graphical user interface. This > includes numerous graphical user interfaces that can not > otherwise be automatically tested. > www.GuiScripting.com Larger Niche market. > > The third level of the technology is built from the first > two levels + another invention allows any set of complex > graphical user interface operations to be intelligently > repeated using a single keystroke or other event. > www.SmartHotKeys.com Mainstream Market Sounds like marketing hype. AFAICT, you don't have anything yet, probably because you are spending too much time on IP than actually trying to get a market for it, niche or otherwise. I see nothing that you implemented with any of this. Where are your products at the web sites? Keep in mind QA automated testing tools have been available for a long time, including GUI, native or WEB. Pushing hotkeys and mouse events is common for the QA testing process. I really hope you don't think you invented anything new here. I see little value for your OCR thing other than for captcha and as I indicated it is a dieing concept. What other images at a web site do you need to automate? -- HLS
From: Peter Olcott on 14 Mar 2010 10:34 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:eeubCwzwKHA.1984(a)TK2MSFTNGP05.phx.gbl... > Peter Olcott wrote: > >>> >>> So personally, if this is for CAPTCHA, I don't see it as >>> worthy endeavor. >> >> This first level of this technology is for (among other >> things) machine to machine transfer of data where no >> other interface is available. >> www.OCR4Screen.com Niche market. >> >> The second level of this technology build from the first >> level + another invention + a whole object oriented >> computer language infrastructure makes a completely >> universal GUI scripting language that can be used for >> (among other things) the automated testing of any >> graphical user interface. This includes numerous >> graphical user interfaces that can not otherwise be >> automatically tested. >> www.GuiScripting.com Larger Niche market. >> >> The third level of the technology is built from the first >> two levels + another invention allows any set of complex >> graphical user interface operations to be intelligently >> repeated using a single keystroke or other event. >> www.SmartHotKeys.com Mainstream Market > > Sounds like marketing hype. AFAICT, you don't have > anything yet, probably because you are spending too much > time on IP than actually trying to get a market for it, > niche or otherwise. I see nothing that you implemented > with any of this. Where are your products at the web > sites? I have to spend so much time making a living working on a job that the one hour a day that I get to work on this does not provide much progress on multi-man year projects. > > Keep in mind QA automated testing tools have been > available for a long time, including GUI, native or WEB. > Pushing hotkeys and mouse events is common for the QA > testing process. I really hope you don't think you > invented anything new here. There are for example no automated testing tools that can automatically test air traffic control systems. There are tools that can test systems, but there are always gaps in what they can test. QuickTest professional (#1 market share) for example can not test QT based multi-platform systems. My system (when I finally get it done) will be able to test any application (zero gaps) and do it with fewer user specified steps. The fewer user specified steps part by itself took several years of design. > > I see little value for your OCR thing other than for > captcha and as I indicated it is a dieing concept. What > other images at a web site do you need to automate? Here is a company interested in my technology for its machine to machine data interchange capability. http://www.karora.com/ Here is a company with a market for a similar product that has far less capability. http://www.screenocr.com/ > > -- > HLS
From: Peter Olcott on 14 Mar 2010 12:24 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:u%237BoYzwKHA.3896(a)TK2MSFTNGP02.phx.gbl... > Peter Olcott wrote: > >>> > > >> 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? > > > What you need to work on is your PROTOCOL - your state > machine, then that will help define all the above. > > In principle, you have: > > 1) you have an UPLOAD/DOWNLOAD protocol to pick: > > - HTTP > - Proprietary required a special client. > > 2) Decide on the PAYLOAD format > > - XML > - SOAP > - MIME > - Proprietary required a special client. > > But as a WEB SERVICE? > > You need to work out your protocol, the state machine, the > client/server response framework. At that point, it > really doesn't matter what vendor or tools are used. > > If you are talking about an extremely simple concept where > you want a "General service" to: > > 1) Transmit an image > 2) Send text response > > Then you need to first work out the INPUT protocol, (1) > the method of sending and the (2) payload format. > > What you decide here will guide you with the development > tools. > > For example: > > 1) For the WEB FORM SERVICE, you only have a HTTP protocol > to use using a FORM submit concept. No choice here unless > you want to force users to use FireFox and others that > support new "SEND DATA" protocols. > > 2) For the machine to machine, you can also still use the > HTTP protocol, but the client now has to do the same job > the browser does, that means learning the HTTP protocol. > If you move away from this, then you are designing a > proprietary protocol. If that is what you want, then the > concepts are properly a little too deep for your here, but > here is the basic idea if you want to get stated on a > machine to machine protocol: > > http://www.codeproject.com/KB/IP/cspserver.aspx > This looks very good, I will study it in depth tomorrow. > > -- > HLS
From: Joseph M. Newcomer on 15 Mar 2010 19:16
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 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 ***** > >>> >>>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 |