From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:%23YrAhQ%23xKHA.3408(a)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?


From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:eUo4lS%23xKHA.2012(a)TK2MSFTNGP04.phx.gbl...
> Peter Olcott wrote:
>
>> I want to prevent malicious users from eating up my
>> service providers bandwidth allocation. I would like to
>> do this in an optimal way.
>
>
> Are you kidding me?
>
> Don't you have in your business plan to get your own WEB
> SERVER and not use GoDaddy?
>
>
> --
> HLS

I think I have a way to minimize abusive users. It does make
it a little more difficult for my legitimate users, but, it
is worth the cost. Everyone must be an authenticated user,
even the free trial users. Every user must have a valid
email address. Every user must prove that they are human
(and not a bot) when setting up their user account. Non
authenticated users have no access. Users that are abusive
simply get their account cancelled. An email is sent to
their valid email address explaining why the account was
cancelled.


From: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
message news:34h8q59dt4fumdnm12viep3ebj3ts15a38(a)4ax.com...
> There are several interpretations to the phrase "raw
> sockets".
>
> For eample, if you don't use CAsyncSocket but use the base
> socket API including the select
> function, you are doing "raw socket programming".
>
> In another context, if you provide the exact packet bits,
> including the headers normally
> provided by your protocol stack (so you can spoof the
> sending IP and Port #, among other
> evil things) you are said to be using "raw sockets".

I am guessing that the is the lowest level understanding of
this term. I think that this one is the one that I was
referring to.

>
> If you creat the socket and specify SOCK_RAW instead of
> SOCK_DATAGRAM or SOCK_STREAM you
> are abole to spoof packets, and this is sometimes called
> "raw sockets".
>
> If you implmenet the low-level protocol (remember the one
> I gave with the length followed
> by a semicolon?) then you are sometimes said to be doing
> "raw" socket programming, even if
> you use CAsyncSocket, because you are implementing the
> stream protocol directly by talking
> to the socket.
>
> If you use a server that implments HTTP, and you handle it
> by having the server route the
> data to your component (external, e.g., a CGI script, or
> internal, what has been referred
> to here as "embedded"), you are not doing "raw"sockets;
> but SOMEONE wrote code to do
> bind(), listen(), accept(), recv() and send(), and whoever
> did that can be said, by some
> interpretations of the phrase "raw sockets" to have done
> raw socket programming.
>
> Note that you do NOT want to implement a protocol other
> than UDP or TCP/IP using raw
> datagrams (where you supply your own headers, for
> example). This way lies madness. Well,
> more madness than whatever madness led to such a decision.
> UDP and TCP/IP are understood
> by every router in the world, and the routers know what to
> do with them. Your own
> protocol will be a mystery, and will Not Play Well With
> Others. That level of raw socket
> programming should be avoided.
> joe
>

That is a very good explanation. Between you and Hector I am
very quickly gaining a very good overview understanding of
web application architecture. I can not study a subject
efficiently until I have a really good overview.

> On Fri, 19 Mar 2010 21:00:25 -0500, "Peter Olcott"
> <NoSpam(a)OCR4Screen.com> wrote:
>
>>
>>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in
>>message
>>news:OwVal18xKHA.5936(a)TK2MSFTNGP04.phx.gbl...
>>> Peter Olcott wrote:
>>>
>>>
>>>> Would I be back to sockets again if I did this? Would
>>>> this be programming at the TCP/IP level or some other
>>>> level?
>>>
>>> Peter you won't be programming in TCP/IP. The socket
>>> library handles all that for you.
>>>
>>> When you open a socket (in TCP mode), try to connect to
>>> a
>>> certain IP address at a certain port, the client (your
>>> software) is already designed to know what SERVER
>>> protocol
>>> he will be using to talk to the remote server.
>>>
>>> In general, when you open port 80, that means you will
>>> be
>>> sending HTTP data over that port.
>>>
>>> The socket stack layer transmits (and receives) using
>>> TCP
>>> packets. Its hidden from you.
>>>
>>> --
>>> HLS
>>
>>I have heard of raw sockets. From what I understand, at
>>this
>>level not all of the lower level is hidden here. What
>>level
>>are raw sockets exactly?
>>
>>Okay so I would be using the sockets library in TCP mode.
>>I
>>am guessing that I could cut out a lot of the HTTP
>>bandwidth
>>overhead by doing this, and have more control over the
>>connection.
>>
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


From: Hector Santos on
Peter Olcott wrote:

> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
> news:%23YrAhQ%23xKHA.3408(a)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
From: Jerry Coffin on
In article <SYqdncgSB6lQ0z_WnZ2dnUVZ_sednZ2d(a)giganews.com>,
NoSpam(a)OCR4Screen.com says...

[ ... ]

> Why is any of this complexity actually necessary in actual
> practice? It would be absurd to be required these days when
> so much RAM is available. If I always have 4.0 GB more than
> I need either your whole point becomes moot, or OS design is
> atrocious.

It's probably not, but you've given a rather oddball request, and
people are trying to answer it.

I think you should step back from all the optimization you're working
on, and instead deal with simply getting the thing working to some
degree. Then you can _measure_ its performance and where it's
spending its time. Only after you've done that do you stand a decent
chance of accomplishing much in terms of optimization -- chances are
that right now you're spending a lot of time and effort on things
that will never matter, and overlooking others that will end up being
crucial.

--
Later,
Jerry.