flashpixx

aber jedes Linux oder Unix kennt diesen Befehl und die Manpages zu den Befehlen sind auch im Netz zu finden und da DD-WRT eine Linux Distribution ist, kann man das auch nach lesen

Warum nimmst Du kein CMS, dann stellt sich das Problem gar nicht

man ssh

Datenbank Entwicklung wäre eher eine FIAE Aufgabe, vor allem für ein Projekt. Ansonsten sind die Infos sehr dünn, entweder benötigst Du ein Warenwirtschaftssystem oder einen Bugtracker. Es gibt für beide Bereiche eine Vielzahl an Anwendungen, sowohl aus dem OpenSource Bereich als auch CloseSource. Du musst aber gerade in einem Projekt erst einmal Deine Anforderungen definieren

Der naive Ansatz würde ich sage, dass Du beim endgültigen Versand das Feld im Header der EMail manipulierst. Das Datum ist Teil des Feldes "Received"

Ich würde auf ein DNS Problem tippen

Eigentlich sollte man die Darstellung entsprechend dem System konvertieren, dafür gibt es auch fertige Funktionen Byte-Reihenfolge D.h. nachdem die Daten konvertiert sind, kannst Du diese richtig codiert in Properties, Listen, Arrays o.ä. ablegen und richtig verarbeiten

Ich schließe mich da an, das löst man mit Exceptions. In Deiner Methode wird bei einem Fehler eine Exception geworfen, im übergeordneten Auf kannst Du via try-catch die Exception fangen (oder auch nicht) und darauf reagieren. Alles andere ist schlechter Stil

Spielt es dann eine Rolle was Ihr einkauft? Im Grunde kauft Ihr doch einen Mailserver, oder? Ob der Mailserver nun Postfix, Exim oder Exchange verwendet ist doch egal. Ihr braucht einen IMAP / POP3 Zugang zu den Mails, Umleitungen und ggf Catch-All. In dem Fall würde ich doch eher nach einem Produkt schauen, was mit die benötigten Featurs liefert, als sich auf eine feste Plattform zu entscheiden.

Sorry, auch wenns OT ist, aber ich würde Postfix definitiv Exchange vorziehen. Das was Du willst lässt sich relativ einfach mit Postfix, Procmail und ggf Dovecot realisieren. Postfix + virtuelle Mailaccounts, die man z.B. in einer mySQL Datenbank ablegt. Roundcube als Webmailclient, Procmail für's verteilen bzw. duplizieren und Dovecot für den Mailclient per POP3 und IMAP. Das ganze noch hübsch über ein SSL Zertifikat absichern, fertig Soweit ich das weiss, brauchst Du für Exchange eine AD, d.h. entweder musst Du im Haus Dich an das AD hängen, dem Server via VPN Zugriff auf das in-house AD geben oder eben 2 ADs pflegen.

Naja, also ob Du jetzt einen weiteren Clone dieses Spiel erstellst, sei einmal dahin gestellt. Aber damit kann man durchaus anfangen, sofern man eben die "technischen" bzw. "praktischen" Sachen einigermaßen beherrscht, so dass man eben mit dem Konzeption beschäftigt und eben auf das Wissen zur Programmierung zurückgreifen kann

cURL

Du möchtest lernen, wie eine Suchmaschine funktioniert: SELFHTML: HTML/XHTML / Allgemeine Regeln fr HTML / Referenzieren in HTML

Binde das Bild als Hintergrund der Tabelle ein, als Div oder Body Hintergrund *klick*

http://de.wikipedia.org/wiki/Switch_(Computertechnik)

Das kommt drauf an, Du hast hier eine direkte Collision, wenn die Kugel ein Objekt trifft. Wenn es dann noch "physikalisch" korrekt sein soll, dann kommst Du sehr schnell in den Bereich der Differentialgleichungen, wobei sich dann direkt ein Problem zwischen Performance und Korrektheit der Darstellung ergibt. Da würde ich mich mal nach einen Studienplatz umsehen... Eben, d.h. Dir fehlt das Wissen und die Erfahrung um es besser zumachen Das kommt auf die Problemstellung an Grundlagen dazu wären: Graphen Repräsentation von Graphen im Computer Dijkstra-Algorithmus A*-Algorithmus Szenengraph Wenn Du diese Dinge leicht und ohne viel Zeit verstehst und dann auch praktisch umsetzen kannst, dann bist Du auf dem richtigen Weg. Ich würde Dir dazu raten, dass Du bevor Du irgendwelche Phantasien versuchst umzusetzen, Dir erst einmal wirklich die Basisgrundlagen aneignest und die Idee ein eigenes Spiel zu erstellen vergisst

und wie willst Du eine Engine ansprechen, wenn Du nicht verstehst, wie Du an diese Daten übergeben musst und wie diese intern verarbeitet werden? Wenn ich ein 3D Spiel entwickeln will, dann brauche ich das Wissen davon, wie es intern funktioniert. Da bewegst Du Dich auf dem Niveau von Quake 1. Das reicht nicht. Wie stellst Du fest, ob Deine Figur gegen eine Wand oder Gegner gelaufen ist?

Es gibt hier mehrere Threads mit dem Titel "ich möchte Spiele in C++ programmieren", bitte verwende die SuFu. Um Spiele auf einem entsprechenden aktuellen Level zu programmieren brauchst Du das Wissen über Lineare Algebra und entsprechende Graphikbiliotheken wie Direct X, OpenGL etc, zusätzlich musst Du eben die Algorithmen aus der Computergraphik beherrschen. Wenn Du das wirklich lernen willst, solltest Du einen Master of Science in Informatik machen, damit Du die notwendigen Kenntnisse bekommst. Vor allem benötigst Du für Spieleprogrammierung eben entsprechende mathematische Kenntnisse, die man in einem Studium lernt

Ich arbeite mit HDF5 nur unter C/C++ (evtl einmal hier rein schauen HDF5 User's Guide ). Im Kapitel 3.8 steht entsprechend etwas zu den IO Zugriffen: HDF5 User's Guide Ich denke, wenn Du das ganze streambasiert machen willst, musst Du Deinen eigenen virtuellen Filelayer schreiben HDF5 Virtual File Layer Ich denke Du musst den Java Stream über einen entsprechenden virtuellen Filelayer den HDF Komponenten unterlegen. Ich denke so etwas musst Du dann via JNI/JNA entwickeln, wobei ich aber überlegen würde, da Du ja anscheinend "nur" Daten transportieren willst, ob Du nicht einfach eine HDF Datei temporär erzeugst und diese dann einfach als Bytestream überträgst und am Zielsystem wieder in eine temporäre Datei umwandelst.

Ich denke, dass das ja das Problem ist, dass Du hier Standard Frameworks verwendest, aber eigentlich etwas individuelleres brauchst. Wenn ich das jetzt OOP technisch sehe, dann müsstest Du doch letztendlich von einem bestehenden System Dein eigenes ableiten können, damit hättest Du doch weiterhin die gesamte Technologie für die bestehenden Workflows, hast aber an den entsprechenden Stellen Deine eigenen Erweiterungen. Im worst-case müsstest Du Deine eigene JTA Komponente schreiben (Java Transaction API).

Man sollte aber auf einen Cast im Allgemeinen verzichten, denn dadurch verändert man die zugrunde liegenden Verteilung der Werte. Die allgemeine [0,1) Randomfunktion liefert eine uniforme Verteilung, die durch das Cast verändert wird. Man sollte immer den für den Datentyp passende Randomgenerator benutzen.

Diese Information hat gefehlt, dass Du hier ein hetrogenes System hast. Im Normalfall ist das eigentlich ja kein Problem, denn man würde ja die Resource, auf der die Nutzdaten liegen einfach homogen setzen. Aber ich stelle hier jetzt die Frage, warum Du Dir gerade bezüglich der Transaktion es so schwer machst. Wäre es nicht sinnvoller zu sagen, dass man ggf eine Resource verwenden z.B. die von Dir genannte Oracle Datenbank und lediglich die Zielsysteme anpasst. Ich meine bei entsprechender Abstraktion muss man nur die Datenbankanbindungskomponenten tauschen. Oder Du würdest die Daten, wie gesagt, auf ein Shared Medium (z.B. NFS) als HDF Dateien legen, jeder Teilnehmer arbeitet darauf und der Koordinaten schiebt später die Daten in die jeweiligen Datenbanken. Der Vorteil wäre hier, dass nur der Koordinator Zugang zum DBMS haben müsste und nicht jeder Teilnehmer Ich arbeite mit MPI, da ist der Begriff "Teilnehmer" als Prozess (z.B. ein einzelner CPU) zu sehen, wobei hier gilt, dass ich den Teilnehmer eben noch über Multithreadding weiter aufbauen kann. Mehrere Teilnehmer kann ich dann zu einer Gruppe bündeln, die dann z.B. eine Node (einen oder mehrere physikalische Rechner) bündeln. Alle Nodes zusammen ergeben dann den Cluster. Die Frage, die ich dabei immer habe, ist die Strukturierung der Daten. Ich hatte ein ähnliches Problem mit 3-dimensionalen Daten, die in Matlab verarbeitet werden sollten und ggf später auch in anderen Systemen. Ich habe die Daten in HDF gespeichert, weil n-dimensionale Daten in einem relationellen Datenbanksystem sehr unperformant werden, vor allem konnte ich durch sinnvolle Skalierung sparse Datenstrukturen verwenden. Die HDF Dateien habe ich dann als BLOB Daten in eine Postgresdatenbank gelegt, dort wurden dann noch weitere Metainformationen abgelegt. Damit hatte ich direkt auch ein Caching implementiert, denn ich habe beim Zugriff die HDF Datei aus der Datenbank geladen und lokal temporär gespeichert, somit musste ich die Session nicht offenhalten. Die 3D Matrizen waren unveränderbar, d.h. nach dem Import brauchten sie nicht mehr verändert werden, so dass ich lediglich dann in die Datenbank Informationen abgelegt habe, die sich aus der Berechnung der Matrizen ergeben haben. Die Frage wäre somit, wenn Du Bytedaten zwischen den Teilnehmern austauschst, ob Du ggf zur Strukturierung HDF verwendest, als die Raw Daten zu übertragen. Wie schon geschrieben wäre wirklich die Frage, was Du überhaupt für Realdaten hast und ob man ggf dieses ausnutzen kann. HDF unterstützt meines Wissen auch Zip-Algorithmen on-fly.

Nein kommen sie nicht. Du hast das 2-Phasen-Commit nicht richtig verstanden (Commit-Protokoll). Entweder es müssen alle Teilnehmer das Ack senden und wenn einer Fail sendet, wird komplett abgebrochen. In dem geschilderten Fall erweitere ich das 2-Phasen-Commit noch mit einem sequentiellen Teil, der durch den Koordinator durchgeführt wird. Nachdem (!) alle Daten berechnet wurden, muss ein Ack von jedem Teilnehmer gesendet werden, wenn ein Fail auftritt wird die Transaktion verworfen. Erst nach dem Ack öffnet der Koordinator eine Datenbanktransaktion in die jeder Teilnehmer seine Daten einfügt. Tritt ein Fehler auf, geschieht ein Rollback der Datenbank und die gesamte vorherige Session wird ungültig. Wenn alle Teilnehmer die Daten eingefügt haben wird der Commit durchgeführt. Damit ist der gesamte Vorgang atomar. Der Koordinator startet die Transaktion und beendet sie. Ich habe auch nicht von "einzelnen Sessions" (Plural) gesprochen, sondern von "einer Session" (Singular). Der Koordinator öffnet eine Session und nur er beendet sie auch wieder, entweder mit einem Rollback oder mit einem Commit. Natürlich muss der Koordinator bezüglich der Datenbanksession den Clients so etwas wie das Sessionhandle mitteilen, damit jeder Teilnehmer in die gleiche Session seine Daten ablegen / erhalten kann. Generell empfehle ich Dir, dass Du Dich einmal mit der Problematik unabhängig von Java befasst, denn die Probleme, die Du hast sind nicht Java bezogen. Du versuchst hier mit vordefinierten Frameworks etwas zu erreichen, was nur schwer möglich ist. Eine Technologie wie JMS kann man durchaus verwenden, nur Du musst sie eben problemspezifisch erweitern. Du wirst hier, wenn Du innerhalb der Transaktion Deine Daten transportierst an sehr große Schwierigkeiten stoßen. Deshalb der Hinweis, dass Du die Daten temporär (innerhalb einer Session über alle Teilnehmer) in der Datenbank lagerst. Wenn die Teilnehmer via InfiniBand an die Datenbank angeschlossen werden, dann wird das Transportproblem sich sehr leicht lösen lassen. Der Nachrichtenaustausch bezüglich der Transaktion ist dann sehr gering, weil nur ein Sessionhandle für die Datenbank mitgeben wird, so dass jeder Teilnehmer Zugriff auf die Datenbank bekommt. Rein technisch: 1. Koordinator nimmt Daten entgegen 2. Koordinator erzeugt Datenbanksession 3. Koordinator schreibt Daten in Datenbanksession 4. Koordinator sendet Nachricht an Teilnehmer mit Sessionhandle 5. Teilnehmer verarbeiten Daten und schreiben Daten in Session 6. Teilnehmer senden Fail oder Ack 7. Wenn Koordinator von allen Teilnehmern Ack erhält starten er ein Datenbanktransaktion, die die Daten aus der Session in die realen Tabellen überträgt und committet 8. Tritt ein Fehler auf, wird Session verworfen bzw. Rollback der Datenbanktransaktion Die Nachrichten zwischen dem Koordinator und den Teilnehmern enthalten lediglich den Status "Ack" bzw "Fail" (bzw. Prepare) und das Sessionhandle. Ein Undo-Log brauchst Du hier nicht, denn die Änderungen an den realen Daten werden erst zum Schluss geschrieben, so dass Du dieses durch die Transaktion der Datenbank absicherst. Generell habe ich die Punkte 1-3, 4-6 und 7-8 in eine eigene 2PC Struktur gelegt und ich sorge dafür, dass diese sequentiell durch den Koordinator ausgeführt werden. Da jede Struktur atomar ist, gilt hier direkt, wenn ein Fehler auftritt schlägt die gesamte Transaktion fehl, da nur im letzten Schritt die Daten in den realen Tabellen verändert werden, brauche ich mich nicht um ein Rollback kümmern, sondern verwerfe einfach die temporäre Session. Tritt im letzten Schritt ein Transaktionsfehler auf, dann macht die Datenbank für mich die Transaktion rückgängig. Generell solltest Du in den Nachrichtenaustaisch keine Nutzdaten legen, sondern die Nachrichten, die die Transaktion koordinieren sollten nur die notwendigen Informationen enthalten, die für die Transaktion benötigt werden. Alles andere gehört in andere Protokolle / Technologien. Außerdem würde man den Nachrichtenaustausch bei den Transaktionen auch als unabhängige eigenständige Struktur entwerfen, damit man nicht hier zwei Dinge vermischt. Entscheidend bezüglich des Datenvolumens ist die Anbindung der Teilnehmer an die "zentrale Datenbank", wobei Datenbank hier nicht zwingend ein DBMS sein muss, letztendlich kann man auch rein dateibasiert die Daten z.B. via NFS austauschen. In diesem Fall würde der Koordinator eben eine oder mehrere HDF Dateien auf ein zentrales Share legen und jeder Teilnehmer holt sich von dort seine Daten. Sollte man feststellen, dass ein Client die Daten nicht mehr in den geforderten Zeitschritten verarbeiten kann, ersetzt man einfach den Singleteilnehmer durch eine Clusterlösung, so dass man hier direkt einzelne Teilnehmer hoch skalieren kann. Da man nur einen zentralen Punkt an, an dem die Nutzdaten liegen, kann man sehr leicht darauf zugreifen.

Beachte die Klammersetzung und den Cast.

Tun sie doch auch nicht, wenn ich das temporär in einer Session der Datenbank mache und bei einem Fehler die Session einfach beende, wäre es so als wären die Daten nie geschrieben worden. Ich habe nie gesagt, dass Du auf Transaktionen verzichten sollst! Ich habe nur gesagt, dass Du die Daten nicht innerhalb Deiner Transaktions-Message transportieren sollst.