Moin Jeroen, moin Liste, >> das sind leider beides nicht gerade Kleinigkeiten, die man mal eben in >> der Mittagspause implementiert. > > Aber doch, ich hatte jetzt einer missbraucht dafür ;)
gib's zu, Du hast Dich da vorher schonmal drin umgesehen:-) >> Das sehe ich etwas anders. Wenn ich die IPv4-mapped IPv6 Addresses >> benutze, kann ich einen Server so bauen, dass er prinzipiell >> unabhängig von der IP-Version immer funktioniert. > > Du meinst einer bei welcher du nicht nach die Adressen guckt. Ja und nein; ich kann grundsätzlich auch alles als IPv6-Adressen behandeln. Dann muss ich zwar in entsprechenden Konfigurationen o.ä. IPv4-Adressen nach IPv6 mappen, aber das geht vergleichsweise einfach. > Jeder Programm das die Versionen an die Anwender durchgebt hat hier > ein Problem. Zurück ist das auch nicht so problematisch: Ich setze alle Mapped Addresses wieder nach IPv4 um, bevor ich sie an den User zurückgebe. Dazu kann ich unter anderem auch getnameinfo(3) statt inet_pton etc. benutzen, dann bin ich komplett AF-independent. > Sicher das problem was du oben beschreibt. Wie kann man > bzw. einer Server allein IPv6 reden lassen? Wenn das Betriebssystem sich an die Standards hält, tut er das sowieso. Ansonsten kann ich mit int v6only = 1; setsockopt(sockd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&v6only, sizeof(int)); /* (Fehlerbehandlung weggelassen) */ explizit sicherstellen, dass ich nur "echte" IPv6-Verbindungen aufbaue. (Steht beides in RFC 3493, Seite 22) > Clients brauchen immer AF-independent programmiert zu werden. Sollte man besser. Aber wenn man Altlasten portieren muss, kann auch das einige Probleme machen, spätestens wenn wie bei FTP IP-Adressen im Datenstrom mitgeschickt werden. Dann muss man zwangsläufig AF-dependent programmieren (und unter Umständen das Protokoll erweitern). >> Das funktioniert >> dann prinzipiell auch über IPv6 hinaus, so dass für ein späteres IPv8 >> Programme möglicherweise nicht mehr angepasst werden müssen. Sicher, >> ich kann mit select(2) auch auf zwei separaten Sockets hören, aber das >> ist zusätzlicher Aufwand, den man sich gerne ersparen will. > > Wann man ein Programm gut programmiert ist das ganz kein Problem, sehe: > http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html - Cut & Paste(tm) > > Meistens wann man einer Programm macht wollt man auch mit mehrere > Clients reden, man muss dann eigentlich bereits all select() oder > ähnliche Techniken verwenden. Ich mache alle neuer Programmen mit das so > das ich dann future-proof bin ;) Hmm, ja. Wenn ich aber select(2) oder poll(2) benutze, dann habe ich ein paar happige Probleme mit langlaufenden Syscalls/Library Calls. Die kann ich gut vermeiden, wenn ich nur einen IPv4/IPv6-Socket habe und nach jedem accept(2) einen Child Process forke (oder zusätzlichen Thread erzeuge, wenn ich will), der das übernimmt. Für manche Server ist es sicherlich nicht verkehrt, wie der Apache einige wenige Child Processes zu forken und dann die eingehenden Verbindungen an sie zu verteilen, aber das ist in vielen Fällen zu viel Aufwand und außerdem schwierig portabel zu programmieren, weil Socket Passing nur bedingt portabel ist. > IPv8 (PIP *) hat übrigens keiner solche Funktionalität. Jajaja, ich weiss:-) Worauf ich hinaus wollte: Mit getaddrinfo(3) und getnameinfo(3) kann man seine Server so programmieren, dass sie auch mit einer späteren AF ohne Änderung funktionieren könnten. ("Könnten" deshalb, weil auch mit IPv6 schon einige grundlegendere Änderungen an Programmen nötig sind, wenn man z.B. einen UDP-Server baut.) Wo wir gerade beim Cut&Paste sind: Ich hänge unten mal meine Beispielprogramme für TCP-Client und -Server an. In tcpserver2.c gehe ich zwar nicht darauf ein, wie man bei der Ausgabe wieder IPv4-Adressen als IPv4-Adressen darstellt, aber eine entsprechende Abfrage mit IN6_IS_ADDR_V4MAPPED() sollte niemanden hier vor unlösbare Probleme stellen. Das ganze ist aus meinem Schulungsmaterial und ist ca ein Jahr alt (getestet mit FreeBSD 5.2.1(?), Debian Woody, Solaris 9). Für den Server sollte man (das erkläre ich in der Schulung) die beiden Macros in chkerror.h durch etwas ersetzen, was Anforderungen der jeweiligen Anwendung besser entspricht --- entweder Logging in ein separates File oder per Syslog ans "zentrale Monitoring". Viele Grüße, Benedikt
chkerror.h
Description: Mein Error Handling Header
tcpserver2.c
Description: Einfacher Demo-TCP-Server (Forking)
tcpclient2.c
Description: Einfacher Demo-TCP-Client
-- Benedikt Stockebrand, Dipl.-Inform. Freelance IT System Architect http://www.benedikt-stockebrand.de/ always looking for a contract Unix (all flavours), TCP/IP, IPv6, IT Security, Unix Operations Training Performance and High Availability Tuning, Large Scale Systems Design
_______________________________________________ ipv6 mailing list [email protected] http://listserv.uni-muenster.de/mailman/listinfo/ipv6
