On 2011-11-26 13.19, H Vlems wrote: I wasn't aware that moving to TCP would result in all that. UDP and TCP both use the same IP addressing functionality. Only UDP is connectionless, i.e. doesn't use acknowledgement messages and is thus a little faster than TCP but less reliable. An IP address change is as much as a problem for UDP as it is for TCP, I'd say. Yes. IP address change is as much a "problem" for UDP as TCP. But at the same time not. :-) In TCP, if the other end changes the IP address, the TCP connection will be reset, and your program will get an error returned. Thus you notice this. In UDP, you will continue to transmit as if nothing happened. In fact, nothing have changed from the UDP point of view. Packets are still sent to that same address. Only, there might now be some other machine receiving them than before. What that machine does is not something you have any control over (of course, a clever prgorammer can make the same happen for TCP, but it requires a lot of work, while in UDP it is the only behavior). There is much more difference between TCP and UDP than the connection/connectionless issue. Of course, you could argue that everything else follows, but not neccesarily. TCP do not have the concept of "packets". It's all a stream of bytes. As such, there is no guarantee that because you wrote 1500 bytes in one write, the receiver will receive 1500 bytes in one read. The receiver could just as well get three reads of 500 bytes each. Also, TCP guarantees that data arrive in the same order it was sent. Thus, if the underlying layer loses a packet, TCP will buffer and resend data in order to keep its guarantee. So later data will be buffered, and not delivered, even if it have arrived, until older data have been delivered. Also, in order to make sure the network is used optimally, TCP can keep from sending data, in order to make packets more "full". This is called the Nagle algorithm, and it can be disabled, but you are still not guaranteed that buffering will not happen somewhere between source and destination, or that TCP won't introduce delays. And then you have various congestion control algorithms, slow start, and what not. And of course, at connection time, you have the handshaking that must happen before the connection can be used. UDP on the other hand guarantees nothing. Packets might be lost, duplicated, delivered out of order, and whatnot. In fact, pretty much (for the most part) just the same as ethernet. And packets are written whole, or not at all, and read the same. One write is delivered in one read. UDP have *packets*, not a stream of bytes. Security is another issue. As you wrote, authentication is sent as clear text so is not secure. Then again, it may only be used if there is a connection to HECnet and that would make no difference anyhow. With the current scheme in HECnet, packets are not accepted from unknown hosts (IP addresses), so random people cannot inject ethernet packets through the bridge to your local ethernet. Also, your local ethernet packets are not sent to any random host, but only hosts you have listed the address for in the bridge program. It is way less than secure, but it do avoid the most glaring problems. Encryption is fine, but it is an up hill struggle: it requires continuous attention to keep up with technology. I doubt if HECnet is worth that struggle. Yeah. I don't think it is. :-) And sorry for the long ramble about network technologies. :-) Johnny -----Oorspronkelijk bericht----- Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens Johnny Billquist Verzonden: zaterdag, november 2011 12:59 Aan: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Integrating with the Italian network. On 2011-11-26 12.48, Johnny Billquist wrote: On 2011-11-26 12.05, H Vlems wrote: What I've read about the "enhancements" to the bridge program is yet another matter. First off, it ain't called bridge for nothing: like any layer 2 bridge the program moves packets between ports and is transparent to both the content of the datagrams and the functionality of the protocol. Including DNS like functionality violates that rule. I also wanted to keep the complexity and overhead down. Otherwise, yes, you could change from UDP to TCP, include SSL, and certificates, to make sure we keep it safe. But that would incur quite some costs both from an administrative point of view, as well as lots more CPU resources to run the bridge, and also more problems in porting it to other systems. To expand, perhaps, a little here. If we switched to TCP, any change in IP addresses would be detected "immediately", since the TCP connection would be lost at an IP change. At that point, the bridge would need to re-resolve the address, and try to establish a connection again. That would have to be repeated regularly until a connection comes up. Since this is very blocking, we'd have to change the bridge to be threaded, so that you have one thread per connection. And then queue packets inside the bridge, with throwing away when queues become to large, in order to prevent other connections from becoming affected. In addition, this would affect the complexity of things like config reloads. Everything is, as usual, doable, but the work involved is not trivial. And then, of course, we have all the certificate issues, and all the code to deal with them. And then, also, TCP can introduce unwanted network delays and burstiness. It really don't fit well with what the bridge do. It provides services not really needed. And I really like simple solutions... :-) Johnny