|
From: rafael M. <raf...@no...> - 2004-03-26 09:55:34
|
On Thu, 25 Mar 2004, Donal K. Fellows wrote: > > The problem with datagram protocols (of any kind) is that they don't fit > well with the stream-oriented paradigm of Tcl channels. While you can > hack it around to make it work, it's a bit of a talking dog. That explains my headache on hacking TCL/IPv6... > (But > anything stream-oriented should be able to fit under a channel without > any problems.) > If I'm not wrong, as traditional TCL model (Channel) does not cover datagram protocol, Stuart's strategy seems to introduce a new model: "Control end point" -> CEP not to overlap the Channel-Socket model... Taking a overall look, it seems a good work, and the signature problem is solved in a natural way. Two new flags are introduced: ?-type type? # You cannot integrate in the traditional channel model ?-domain domain? # the same "-family" flag I proposed. > > * Multihoming enabled: The current implementation only saves the > > pointer to one addresses, instead a list of linked > > addresses...(struct addrinfo). This may originate DNS resolution > > problems while transition into IPv6... > > Not an issue I understand enough to comment on. > OK. Very easy. Let's try to explain: - Suppose actual TCL socket system TCP/IPv4. You are programming a MUA , trying to access the SMTP server: mail.server.com: This server has two IP's interfaces: 213.56.125.3 for the public Internet, and 10.0.0.3 for the Intranet. Your firewall/router at 10.0.0.1 cuts off all the ports but those of HTTP and FTP. From the Intranet, your TCL programmed MUA, tries to solve the address mail.server.com and it gets "213.56.125.3". As the firewall does reject your request, you get "connection error" as it the remote server were down. However if you type de dot address "10.0.0.3" instead of mail.server.com , you will get connected as expected. Multihoming, implemented at C API (gethostbyname(),getaddrinfo()), but wasted by actual TCL implementation, would allow you to try alternate resolutions at "socket" TCL call, as the DNS returns you a list ok list of linked addresses ("213.56.125.3","146.56.145.2","10.0.0.3"). Now , the IPv6 transition may make it harder. Full transition will take some years, and meanwhile, on the first times , most clients will have no IPv6 connectivity, but DNS running on IPv4 WILL SOLVE to IPv6 addresses (now they are), even preferently to those on IPv4: I.e mail.server.com -> ("2003:546a:e474:3bf::10","213.56.125.3","146.56.145.2","10.0.0.3") Some versions ago, this was a detected bug on a famous browser... I think Stuart's strategy is missing this point . Not sure,I have to check more deepthly. Ready to colaborate ? > > * Should we enable a new flag to filter the DNS search ? > > "-family".... > Stuart calls it "-domain". > I'd have thought that the addressing family would be implicit in the > protocol type. But protocol type does not imply the family... You can have UDP-IPv6 , UCP-IPv4, TCP-IPv6, TCP-IPv4... > Separating that would add a lot of complexity for no > gain to the 99.99% (add extra 9's to taste) of Tcl users who don't want > it. Let's try to keep common stuff easy. > I do agree. TCL is not designed to make fine networking.... > The other issue with that statement is the assumption that name > resolution is done by DNS. That's not universally true, alas. > Well, resolution on /etc/hosts is dealed on an abstract way on gethostbyname(), getaddrinfo()...which are standing on TCL implementation. > Donal. > Cheeers. Rafa. |