From: Hector Santos on
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
From: Peter Olcott on

"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.


From: Hector Santos on
Peter,

When it comes to the internet, you can only expect compliance with
good guys. You can't stop bad-guys. They won't listen to you, your
rules or anyone elses. The only thing you can do is issue a
disconnect (close the socket, "hangup the telephone") and monitor the
IP for redundant bad behavior, then block the IP.

--
HLS

Peter Olcott wrote:

> OK great is this before or after my bandwidth quota has been
> hit with the full data load?
>
> In other words could a lower level protocol such as TCP/IP
> send a large portion of the file before my HTTP gets a
> chance to reject it because it is "denial of service attack"
> size?

>

> Alternatively could I somehow structure my code so that I
> only get just the bytes indicating the size and reject all
> other data before eating up any more of my bandwidth quota?
>
> example I only see these bytes---->"size(1000000000)" and
> reject the file before any additional bytes hit my bandwidth
> quota.
>
> NOTE the only valid data sent to my web application will be
> a single 24-bit PNG file that can vary in size up to a
> predetermined limit of something like 10K.
>
>


From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:%23OJgTK9xKHA.5940(a)TK2MSFTNGP02.phx.gbl...
> Peter,
>
> When it comes to the internet, you can only expect
> compliance with good guys. You can't stop bad-guys. They
> won't listen to you, your rules or anyone elses. The only
> thing you can do is issue a disconnect (close the socket,
> "hangup the telephone") and monitor the IP for redundant
> bad behavior, then block the IP.
>
> --
> HLS

If I configure my (java applet based) protocol as I have
explained in another message, I might even be able to
prevent the bad guys from impacting me very much. If the
first six bytes are not what I expect, I disconnect. The
signed (thus unmodifiable) java applet enforces the
proprietary protocol, and no other protocol can produce the
correct first six bytes. (It might take a few more bytes).

I am guessing (and I think that you said) I can also reject
abusive IP addresses. Hopefully this requires little
overhead. Possibly I can have the hosting provider reject
them for me, thus costing zero of my bandwidth budget.

>
> Peter Olcott wrote:
>
>> OK great is this before or after my bandwidth quota has
>> been hit with the full data load?
>>
>> In other words could a lower level protocol such as
>> TCP/IP send a large portion of the file before my HTTP
>> gets a chance to reject it because it is "denial of
>> service attack" size?
>
> >
>
>> Alternatively could I somehow structure my code so that I
>> only get just the bytes indicating the size and reject
>> all other data before eating up any more of my bandwidth
>> quota?
>>
>> example I only see these bytes---->"size(1000000000)" and
>> reject the file before any additional bytes hit my
>> bandwidth quota.
>>
>> NOTE the only valid data sent to my web application will
>> be a single 24-bit PNG file that can vary in size up to a
>> predetermined limit of something like 10K.
>
>


From: Hector Santos on
Peter Olcott wrote:

> 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?


Any data that is not processed is RAW. :)

You got raw sockets and raw packets. In OCI Model, raw packets can be
defined to be at the data link level 2, raw sockets at the IP
networking level 3.

Example, PING utilities use raw sockets.

> 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.

I don't get you. You have no choice but to use TCP based sockets if
you want to do HTTP, FTP, SMTP, NNTP, IMAP, POP3, etc, programming.

Your "socket program" become "HTTP Program" only because of the
agreement between what data you will be sending and the remote server
will be receiving - the HTTP formatted data.

Your "socket program" become "SMTP (EMAIL) Program" only because of
the agreement between what data you will be sending and the remote
server will be receiving - the SMTP formatted data.

And so on and all cases, you have the same functions:

socket() - pick up your telephone
connect() - dial and answer
send() - TALK ENGLISH
recv() - HEAR ENGLISH
close() - hang up

what makes it HTTP, is what you send and receive() over the
connection. No more.

The simple example is sending two lines as one string:

CString s = ""
s += "GET /HOMEPAGE.HTM HTTP 1.1\r\n";
s += "HOST: peter.com\r\n";
s += "\r\n";

send(hsocket, s, strlen(s), 0);

Your web server, see the GET line, reads HOMEPAGE.HTM from the server
"root document" folder and dumps it out using the send() command itself.

Now you read what the server sent, using recv() in some loop:

char buffer[1024*8];
int len;
while ((int len =recv(hsocket,buffer,sizeof(buffer),0)> 0) {
// I'm a web browser, display the html
DisplayHTML(buffer, len);
}

Thats it! Its all SOCKETS!


--
HLS