Hi!
On 10:25 Sun 28 Nov , Ian G wrote:
> On 28/11/10 5:38 AM, Jérôme Prudent wrote:
> > Hi!
> >
> > Sorry for the off topic (and the stupidity of the question), but could
> > you briefly explain me what's wrong with the use of UDP?
>
>
> 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.
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.
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.
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.
-Michi
--
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com
_______________________________________________
p2p-hackers mailing list
p2p-hackers@lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers
