Hi Michael, On 28/11/10 7:12 PM, Michael Blizek wrote:
>> Only that it isn't used enough :) >> >> http://iang.org/ssl/reliable_connections_are_not.html > > I do not really get the point of this page. The dogma in most programming is that /if/ you need to reliably send some data in an application, /then/ you should use a reliable connection like TCP/IP. What this page is about is saying that the dogma is wrong. Using a reliable connection is approximately reliable, but if you really need real reliability, it just isn't up to the job. So you have to (and most apps do this) provide a reliability layer over the top anyway. Now, if you have to provide that reliability layer over the top ... anyway ... many times you're better off doing the job properly. And switching to UDP / datagrams from the very start. It's basically about saying -- you know all those engineering problems you have in the upper layers, trying to make your app slick and reliable? A lot of them are to do with an original flawed assumption you made a long time ago -- to use TCP. > 1) You *can* send+receive raw IP packets and do your own TCP/IP implementation > in userspace if you want. This is what sniffers and many "security" tools do. > I see no problem in modifying at least linux to do this even with non > privileged programs, if the operating system still does manages the ports. But > seriously doubt that this will make TCP faster and less bug-prune. It will > very > likely do the exact opposite. After all, people who have no clue would start > reinventing segmentation, reordering, retransmit including acks and their > timing, windowing including SWS avoidance, congestion avoidance, path MTU > discovery, connection setup including syncookies and a lot of other stuff. Yes. The question is, what do you need? Many applications don't need all of what TCP offers. Think of it this way: how many applications are stream oriented? Almost none. HTTP is not; it's datagram oriented, a request-response model, GETs going out, HTML coming back. Even stream oriented apps like VoIP use lossy streams :) > 2) It is *impossible* for both the sender knowing the receiver has received > and processed the data *and* the receiver not starting to process the > received data before it knows the sender knows it has processed them. If you > have this problem, you provide the sender with a way to query the status any > time, independant of any session. Yes, factor in the coordination problem, a.k.a. two generals problem. The point being that your app also has these problems, anyway. Figure out what you need, and chances are you need it anyway, regardless of what the connection offers. Simple example: older websites for payments used to have a label on the PAY-NOW button saying "don't click twice!" The problem was that there were many bugs in the various stages that triggered resends. Simplistically, developers thought the users were pushing the buttons twice. And they were, sometimes. But there were other things too. So the solution was to have every purchase form include a unique cookie, and then strip out any duplicates. So, now we've added a datagram integrity feature, layered over the top of HTTP over the top of SSL over the top of TCP. Hence, the integrity features in the lower layers are now redundant, in some sense or other. > 3) If your firewall is so closed that only HTTP gets through so be it. People > building websites often do not know what they do. No transport can provide you > with a guarantee that there will be no network errors. NATs have to be dealed > with at application level in some cases and some people try to create insane > workarounds. A man in the middle may intercept all data. Seriously, what does > this say *against* TCP? That people using it have no clue? > > OK, TCP could be build to survive IP address change of one side. Do we want > this? Doesn't this negate many of the privacy benefits we have with dynamic > IPs? > > Maybe we could protect better against MITM and other attacks. But this is not > is easy as it sounds, because key setup has to be done right. Right, there are so many problems at so many layers that the job has to be done properly. By the time you've done the job properly, you don't need TCP, anything it does is likely not that helpful. (Note that there is one caveat to all of this: If you need reliability. If you don't need reliability, ignore that page. E.g., HTTP doesn't really need reliability, pages get dropped all the time, and there is a reliability feature in the user, "click reload".) iang _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
