[Nottingham] Odd behaviour in KDE

[Lee]

  I remember one case where 
> TCP/IP was hiding broken hardware flow control on a modem :)  It would adapt 
> to exactly the rate that worked, to avoid the modem needing to stop the 
> host's transmission.
>

nice :-))) perhaps that the two cups and a bit of string I was talking
about.

  I might try  out one of the Internet capable protocols soon, 
> was thinking about Intermezzo.

hmm, sounds interesting, coda's another one (cifs) .... not had time to
play with them though..

>
> Actually quite a few ppl suffered data corruption with NFS, because by default 
> UDP checksums were turned off in SunOS 4, fine in Ethernets and over X.25, 
> but when fast serial lines started getting used without the Level 2 
> protection, the problems soon  showed.
>

Ouch.... that's nasty, thank you very much sun,  I can see why they did
it, for speed, but if layer 2 aint checking, and layer 3 aint checking,
then it's up to the application....ooh...nasty.......turning of
checksumming...where they on crack or something.. I mean even if layer
2, is doing checking, I've seen instances where a machine has been
corrupting packets via the networks card to memory (now and then) , so
not all error's can be caught with layer 2 checks...beware... intresting
enough, tcp still worked fine on this braindamaged machine, were other
protocols failed! nice!

> TCP re-orders and checks the transmission in kernel memory.  This implies 
> buffering resources, so it can simply retransmit missing packets.  Though if 
> the IP layer fragrments the packet, then the whole of that would be 
> re-transmitted, as there's no way the sender can know which fragment was 
> dropped.
>

re-orders in kernel memory...yeah..dos attack anyone... :-).

yeah, fragmentation, best to try and avoid fragmentation, what's the
maxium MTU for the internet these days? 512? or something.. 
> 
> NFS security was meant to be achieved via secure RPC calls.  Due to Co-Com 
> export restrictions though, Sun couldn't export a software encryption 
> implementation, or their hardware crypto-chips, which made for an empty slot 
> in most European workstations.

oh dear :-(, secure RPC...sounds interesting... I always found RPC a bit
of a black art myself, it's intresting stuff, but very few really
understand what it's doing, you are the very few Rob :-).... This whole
msblaster stuff at the moment, all down to RPC, microsoft love it, thier
whole nt system is build on that..finding out *exactly* what's going on
is impossible...well for a mere mortal anyhow..

rpc is really powerful stuff, it's a lot of fun too.... and for
security..it's the one to look for first.. :-))))

  Friendly governments were able to source 
> those chips, for use by military etc  I know because colleagues in 
> Switzerland, were consulting in certain sites where you needed security 
> vetting.
> 

hmmm, security for those with the $$$$

> > Packet loss during the inital tcp 3 way handshake could be real bad
> 
> Won't the connection attempt simply be retried?
> 

you would think so in theory..., I've seen NT just 'forget' about tcp
connections in the presetup state...but then it's lame-o ip stack
anyway..

> 
> A believer in end to end protocols :)  How does 802.11b's retransmission 
> operate?
>

uses a wireless ack at the linklayer, so a three way tcp handshake
actually requires 6 packets.., ..... that's why performance is so go
damm awfull on 802.11b,..and you can't turn it off either.......shame it
would be really useful for point to point links.... if you turn rts/cts
protection on, your looking at even more overhead.......soon eats into
your throughput.. I've got a work around than I'm testing at the moment,
to avoid wireless ack's, yeah, I want turn them off, call me crazy...

> > it's only when you really look a tcp this close, that you find it really
> > is not that clever..but it works....we just need bigger pipes, and less
> > people using microwave oven's....hahaha
> 
> Oh it is actually really very clever, it's really hard to design something 
> that is  simple and elegant enough to implement well.  Most applications that 
> start off UDP/IP end up with a TCP/IP option, because it's really quite hard 
> to do a better job.
> 

I Agree...perfect design is not when you can can't add any more
features, it's when you can't take any more features away...

or something like that ;-).

Laters,
Lee