How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Hector Santos on 19 Mar 2010 21:33 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 19 Mar 2010 22:00 "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 19 Mar 2010 22:11 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 19 Mar 2010 22:45 "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 19 Mar 2010 22:50
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 |