"Joseph M. Newcomer" <newcomer@flounder.com> wrote in
See below...
On Sat, 20 Mar 2010 09:29:11 -0500, "Peter Olcott"
<NoSpam@OCR4Screen.com> wrote:
"Hector Santos" <sant9442@nospam.gmail.com> wrote in
message
news:eUEo4l%23xKHA.5364@TK2MSFTNGP05.phx.gbl...
Peter Olcott wrote:
"Hector Santos" <sant9442@nospam.gmail.com> wrote in
message
news:%23YrAhQ%23xKHA.3408@TK2MSFTNGP06.phx.gbl...
Peter Olcott wrote:
I just want to understand how the handle the most
malicious user in the most robust way. If I can block
an IP address without costing me any bandwidth, then
I
think I have one significant aspect of blocking the
most malicious user.
As joe puts it, you are "obsessing" again :)
Its very simple with the server model:
s = socket() - create a socket handle
bind(s) - associate an local IP with
socket
s handle
listen(s) - starting to listen to
connection
accept(s,c) - wait for clients, new socket c
for connect
CHECK PEER IP ADDRESS OF C IN FILTER LIST,
IF FOUND, CLOSE SOCKET GOTO BACK TO ACCEPT
recv(c) - receiver whatever
send(c) - send whatever
shutdown(c) - tell remote I'm about to close
closesocket(c) - close socket handle
go back to accept
--
HLS
That does seem pretty simple. Would I only need a
single
recv(c) for a 10 MB file?
No, a recv() is a loop and you read 8K at a time:
FILE *fv = fopen(szImageFileName,"wb");
char buf[8*1024] = {0};
for (;;)
{
int len = recv(c,buf,sizeof(buf),0);
if (len <= 0) break;
fwrite(buf,len,1,fv);
}
fclose(fv);
But the above is very simplistic.
Mongoose.c, without verifying but I trust it will,
otherwise it isn't a web server, will same the POSTED
data
in some temporary file for the transaction (while the
connection is alive). That FILE NAME is then passed
your
CGI script or whenever is going to process the posted
data.
So it should be done for you. You just need to learn
how
Mongoose implements this fundamental web server idea.
Again, if it doesn't handled POSTed data for you, then
GET
RID of it, it isn't a real web server of any kind.
But I know it does because its fundamental and a HTTP
standard requirement to handle POST correctly and that
includes save the data somewhere for the session to
process.
--
HLS
That is great Hector. It looks like the basic
architectural
design is set. I won't limit myself to mongoose in the
long
run.
****
Note that what is illustrated here is what is called an
"iterative servier", that is,
while it is processing one transactiion, it cannot accept
other connections, because it
needs to go back to the Accept statement. There is also a
concept called a "concurrent
server" where you hand the accepted socket over to a
separate thread and immediately
return to the Accept statement. In this case, you can
handle multiple connections. Note
that if you are using CAsyncSocket for the Accept target,
then you will have to detach the
socket handle from the CAsyncSocket object, pass the raw
socket handle to the thread, and
re-attach the handle (using CAsyncSocket::FromHandle) to a
CAsyncSocket object in the
thread, to keep MFC happy. See my essay on UI threads.
In general, if you want maximum thoughput you will want to
consider a concurrent server
architecture. These are discussed in deail in Comer &
Stevens volumn III (Windows
edition).
joe
FIFO queue, then this thread dies. My OCR process would read
http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers
One of these might prove to be better in the long run.
Another design constraint is very high security. That will
require another whole learning curve.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm