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 17 Mar 2010 11:52 "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 17 Mar 2010 13:13 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 17 Mar 2010 13:38 "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 17 Mar 2010 14:45 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 17 Mar 2010 14:51
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 |