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 23:04 Peter, I already lost a few other messages I posted answering some these questions, so I will keep it short here. :) Peter Olcott wrote: > 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. You have no control over what kind of bad guys will attempt to abuse your server. You have only one design option: - issue errors and if they don't listen - disconnect - mark the ip, - if already marked block them for X time or forever policy. Now, I think you are overly concern about this since I believe you said your transactions will be authenticated. If so, your abuse is a lot less and the only concerned are compromised users which will be pretty rare IMO. Unless you become a MAJOR ATTRACTIVE site worth attacking, just follow basic ideas and quite tying to control every aspect of your design. Get something completed first. > 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). If you plan to use a Java client, you have more control over the client/server nature of your transaction and you can do pretty much anything you like. But you still have to protect the server. > 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. Do it mongoose. Easy stuff. -- HLS
From: Peter Olcott on 19 Mar 2010 23:06 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:uLpeZg9xKHA.812(a)TK2MSFTNGP06.phx.gbl... > > 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 That makes things much clearer, yet, not quite yet completely clear. From what I understand, If I embed a webserver into my code, then I would be communicating with the webserver using HTTP which is a higher level abstraction than sockets, and the webserver code would be providing this higher level interface to me and handling the lower level details of sockets for me. Is this right?
From: Joseph M. Newcomer on 19 Mar 2010 23:29 See below... On Fri, 19 Mar 2010 16:46:53 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:cpq7q5dbueo4bee9225aioscqp3evsec0d(a)4ax.com... >> See below... >> On Thu, 18 Mar 2010 13:33:43 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >>> >>>It looks like I am going to be using HTTP as the protocol. >>>I >>>just bought two books on it. I am estimating that the >>>TCP/IP >>>is mostly invisible at the HTTP layer. I am using the HTTP >>>protocol because it seems that the HTML element that I am >>>using, sends the data using this protocol. >>> <input name="userfile" type="file" accept="image/png" /> >>> >>>Using HTTP is it possible to reject a file that is the >>>wrong >>>format before the entire file is sent? >>>Using HTTP is it possible to reject a file that is too >>>large >>>before very much of this file is sent? >>>One way or another (the least effort way) I will be able >>>to >>>make sure that my data remains (at least mostly) in >>>physical >>>RAM. I will address this later on, since this is merely an >>>implementation detail. I always proceed with development >>>using a strict hierarchy of increasing specificity. It is >>>best to go this way because many of these details often >>>become moot before final design is complete >> **** >> As far as I know, if you tell HTML client-side that a >> particular file is PNG format it >> trusts you and sends it as a PNG file. If it isn't, the >> server side is going to have to >> deal with that. Of course, this may be >> implementation-specific to a particular browser. >> joe > >Yes but the crucial aspect of this question that you ignored >is whether or not I can reject a file BEFORE I have paid for >ALL of its bandwidth. If not then a simply denial of >service attack could simply send huge files until my quota >is used up. If you skip any part of this message, please do >not skip this part. *** I did not ignore it; I said that the default behavior, as far as I know, is to trust the user to no send an incorrect file. If you want to do more, you will have to write a Java applet or some JavaScript that looks at the file and validates it. Based on my deacade-old memories of doing this, if you tell the user to select a PNG file,and you upload it as mime/png, and it is GIF or BMP or TXT, the contents of the file are send up, and the mime format you claim is a lie; in that case, you app has to validate it as best it can and if it fails you can send back some HTML of the form <html> <body> <h1>And what part of "PNG" file did you fail to understand! This wasn't a PNG file. Next time follow directions</h1> </body> </html> or something possibly a little less strong. But i is up to you to validate that the file has the correct format. I could say ren mumble.txt mumble.png but that doesn't make it a PNG file, so you still have to validate. If you do it client-side you have to do the same algorithm while running some form of client side scripting, so why bother? If the user sends a bogus file, let the server complain! It is probably easier to write the code on the server (a friend who used to do a lot of client-side scripting now does only server side work:His claim is tha JavaScript is too dangerous so too many people disable it; and for Java you can only write in a subset of Java 1.0 because that's all you can expect will be available on the client side, and they probably don't have Java at all, so it won't run at all. His company has stopped doing other than the simplest HTML 3.x (now presumably 4.x, but you can't rely on browsers supporting .5.x yet). They do all the validation work on the server side, because they can control what is going on and all browsers implement the core HTML 3.x (at the time I talked to him about this). So don't get hung up on doing the validation on the client side; assume clients will lie to you and you have to validate on the server side ANYWAY. joe **** > >If I can not reject a file at the HTTP level, then I have to >work at a lower level. In the ideal case I can receive the >file size before any of the rest of the file is sent, and >reject is with only a few bytes of wasted bandwidth. After >I determine that the file is not too large I then get >however many minimal bytes are required to determine the >file type, and then reject the rest of the file if it is not >24-bit PNG. **** If they send the wrong thing, why should you care about them wasting bandwidth? it won't happen often enough to justify the additional (unrobust) client-side complexity. **** > >A lot of this risk could be mitigated by user >authentication. Some of this risk could not be mitigated by >user authentication because I want to provide a trial of my >service for free. I could reduce this risk too by requiring >user accounts even for my free customers. If they send a >huge file, I cancel the account that it came from. **** There's no "risk", because in any sane system you WILL validate the file format; you are living in some kind of dream world if you think every transmission you receive is going to have valid data. I would never make this assumption, nor would I wast time duplicating at the client side (using complex scripting or applets which might reduce my site's usability) the same validation I will HAVE to do at the server side. Perhaps you have heard of the sociopaths that will try to bring down a server by sending it bogus packets? They'll try to figure out how to do denial-of-service and privilege-escalation attacks by sending ill-formed data to your site. So you HAVE to validate the data! Why waste effort trying to do it client-side? I did not ignore the question, I just thought it was a pointless question to answer because it makes no sense to try to do this client-side and then naively assume all data you receive is valid! joe **** > >> . >>> >>>>> >>>> Joseph M. Newcomer [MVP] >>>> email: newcomer(a)flounder.com >>>> Web: http://www.flounder.com >>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > 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 19 Mar 2010 23:33 Peter Olcott wrote: >> 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. > That makes things much clearer, yet, not quite yet > completely clear. From what I understand, If I embed a > webserver into my code, then I would be communicating with > the webserver using HTTP which is a higher level abstraction > than sockets, and the webserver code would be providing this > higher level interface to me and handling the lower level > details of sockets for me. Is this right? Pretty much. All internet programs use the socket library available for the OS. For Microsoft its calls WINSOCK (WINSOCK2 is every more Windows specific stuff), but basic sockets is WINSOCK and at the most basic level: s = socket() - create a socket handle connect(s) - connect to IP at PORT # send(s) - send whatever recv(s) - receiver whatever shutdown(s) - tell remote I'm about to close closesocket(s) - close socket handle The above is a basic client application, because it uses connect(). A server application uses: 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 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 What makes it a web is PORT 80 or PORT 443 for SSL (HTTPS). Any other port is a special relationship and agreement that the client has to know, like port 8080. http://peter.com <--- connect to default port 80 http://peter.com:8080 <--- connect to port 8080 But to be a real WEB CLIENT and WEB SERVER regardless of what port they use, they must exchange HTTP formatted lines. Sending anything breaks it. Now you have Helper libraries or "High Abstractions" you want to call it that. MFC CSocket and CAsyncSocket are OOP abstractions of the WINSOCK/WINSOCK2 library. But that isn't HTTP library. Microsoft has MFC HTTP classes too: CHttpConnection CHttpServer See the CHttpXXXXXXXX MFC classes. Mongoose has special HTTP lawyer over WINSOCK that makes it easier to prepare a web server and read the HTTP data, for example mg_get_header() allows you to read one of the HTTP header lines. The MFC CHTTPxxxx class has the sort of idea. All good HTTP socket helper libraries has functions to deal with the HTTP data for receiving and sending. You have to study the rest of the HTTP functions in mongoose.h -- HLS
From: Peter Olcott on 19 Mar 2010 23:34
"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:u2eM6n9xKHA.2644(a)TK2MSFTNGP04.phx.gbl... > Peter, I already lost a few other messages I posted > answering some these questions, so I will keep it short > here. :) I have responded to every one of them that giganews has sent to me. > > Peter Olcott wrote: > >> 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. > > > You have no control over what kind of bad guys will > attempt to abuse your server. You have only one design > option: > > - issue errors and if they don't listen > > - disconnect > > - mark the ip, > > - if already marked block them for > X time or forever policy. > > Now, I think you are overly concern about this since I > believe you said your transactions will be authenticated. > If so, your abuse is a lot less and the only concerned are > compromised users which will be pretty rare IMO. Unless > you become a MAJOR ATTRACTIVE site worth attacking, just > follow basic ideas and quite tying to control every aspect > of your design. Get something completed first. Does the mark the IP cost me any future bandwidth? I always design completely before coding. When I finally get to coding everything works the first time almost completely free of any logic errors. I do not begin coding until the design provides an optimal solution. Something like 90% of my time is spent on design, 5% on coding and 5% on validation. Validation mostly includes test design. > >> 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). > > > If you plan to use a Java client, you have more control > over the client/server nature of your transaction and you > can do pretty much anything you like. > > But you still have to protect the server. > >> 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. > > > Do it mongoose. Easy stuff. I want to make sure that my architecture considers every future need, and the long term design is optimal. The short term physical implementation may take short-cuts, initially. > > -- > HLS |