Friday, 31. October 2008Empfangendes Interface bei UDP-Kommunikation finden
Ich schreibe zur Zeit privat an einer kleinen RIS (Remote-Installation)-Lösung, mit der man übe rPXE ein Betriebssystem bequem und einfach übers Netzwerk installieren kann.
Dafür wollte ich auch ein kleines Feature einbauen, mit welchem man Tokens (derzeit nur einen Token) im Textfile, welches die Menüstruktur des PXE-Menüs beschreibt, hinterlegen kann, welche dann entsprechend ersetzt werden. Konkret handelte es sich um einen Token, welcher die IP-Adresse des TFTP-Servers angeben soll. Um Knoppix über PXE zu booten, habe ich das gepatchte Koppix verwendet, welches statt über NFS auch über SMB booten kann. Hier der entsprechend gepatchte Knoppix-Kern. Leider benötigt dieser bei der Pfadangabe des zu bootenden Servers unbedingt die IP und kann den Namen scheinbar nicht auflösen. Da ich den Server aber möglichst flexibel halten will, dachte ich mir, ich lasse meinen TFTPD einfach die IP des Interfaces einsetzen, über den der TFTP-Server den Client bedient. Doch das herauszufinden gestaltet sich leider alles Andere als einfach. Ich binde den TFTPD auf alle Interfaces (INADDR_ANY). Danach verwende ich recvfrom und sendto , um Requests zu erhalten bzw. zu beantworten. Damit funktioniert das Ganze ja recht einfach, beim recvfrom erhalte ich die CLIENT-Adresse, die ich bei sendto wieder angeben muss. Doch wie bekomme ich die IP des Interfaces?Die erste Idee war, getsockname nach dem ersten recvfrom zu verwenden. Unter BSD-Artigen Systemen ist in der resultierenden Strutur dann die jeweils verwendete Adresse zu finden (sockaddr_in ). Groß war die Ernüchterung, als unter Windows jedoch 0.0.0.0 drinnen stand. Warum das so ist erklärt der Artikel Q129065 der Microsoft Knowledge Base.Na prima, dort steht eindeutig: Applications should not assume that they can get the IP address of the interface.. Damit wollte ich mich aber nicht zufrieden geben. Irgendwie muss es doch möglich sein, trotzdem das zuständige interface herauszufinden. Schließlich kam ich auf folgende Idee, die als Workaround ganz gut funktioniert: Von recvfrom ist ja die IP des Clients bekannt. Also müssen wir Winsock einfach fragen, welches Interface die beste Route dorthin hat. Mein Workaround:
Gewinnt zwar keinen Schönheitspreis, aber mir ist auch keine bessere Lösung dafür bekannt. Wednesday, 1. October 20086bit auf 8bit Farbpalette konvertieren
Der Maskenhandler für die Terminalausgabe von unserem Softwarepaket unterstützt auch ANSI-Color Farbterminals mit einer 6bit breiten Palette (sprich 64 Farben).
Hat man jedoch gerade kein Terminal bei der Hand, kann man auch einen Terminalemulator wie z.B. PuTTY verwenden. Dieses unterstützt bereits 256 Farben nach der xterm-Emulation. Nun wollte ich also auch auf meinen xterm Farben haben und nicht immer nur mit vt100 herumzugrundeln. Aus diesem Grund musste also die 6bit - Palette auf eine 8bit Palette gemappt werden. In unserem termcap-File konnte man auch die einzelnen Farbwerte definieren, bloß welche Werte nehmen, wenn man eine größere Palette hat als die verwendete EGA-Palette? Ich habe im Internet nach einer Mapping-Tabelle oder einem kleinen Konvertierungsscript gesucht. Nach langem, vergeblichen Suchen habe ich dann schließlich beschlossen, selbst ein kleines Programm zu schreiben, welches die Konvertierung vornimmt: Zuerst werden beide Paletten im Speicher angelegt, dann wird die 6bit-Palette durchgegangen und jeder Eintrag wird an den nähesten RGB-Wert der 8bit Palette angeglichen. Dieser Index wird dann genommen und siehe da: Die Palette ist konvertiert. Das Programm schreibt einfach die einzelnen Farbstufen und den zugehörgen Palettenwert in unserem Termcap-Format auf stdout. Viell. kann es ja auch einer meiner Leser brauchen? Quellcode gibt's jedenfalls hier. Compilieren einfach mit gcc -o palette palette.c oder mit jedem beliebigen anderen C-Compiler.
(Seite 1 von 1, insgesamt 2 Einträge)
|
SucheBlog abonnierenTop ReferrerVerwaltung des Blog |