VaNaTiC

im Normalfall 32bit nach IEEE 754, also die "Hälfte" von double

Propietäre Lösungen sind inkompatible, nicht dem Standard entsprechende, von einem Hersteller entwickelte Lösungen für dieses Problem: - Hiper-Ring von Hirschmann, - Fast-Ring-Detection und erweiterte Switchanzahl von Phoenix Contact, - Turbo-Ring von Moxa, - EKS, SIEMENS und andere haben auch alle mehr oder weniger tolle Erweiterungen, Verbesserungen. Bei einer Schleife laufen sich sämtliche Netzwerkpakete tot und das macht den Ring innerhalb kürzester Zeiten taub und stumm.

Um genau Dein Beispiel aufzugreifen finde ich, solltest Du ein group by kundennummer machen. Vornamen sind öfters identisch und auch Nachnamen reichen nicht zweifelsfrei. Für die Funktionsweise ist das egal, nur die Ergebnismenge kann sich u.U. ändern

In einem typischen Szenario eines RABT-Tunnels bauen etwa 10-15 LWL-Koppler einen redundanten Ring auf. Und dabei sind Rekonfigurationszeiten von unter 100ms notwendig.

Wenn Deine Frage soweit geklärt ist, dann würde ich gern eins zwei Sachen wissen, die nicht ganz OnTopic sind. Ich arbeite auch im Automatisierungsbereich (Gebäude, Tunnel, Verkehr) und durfte selber schon (negative) Erfahrungen mit STP, RSTP und propietären Ring-Protokollen sammeln. Ist das ein "echtes" Problem, oder ein Testszenario? Denn STP ist für ein Automatisierungssystem viel zu langsam, selbst RSTP taugt noch nicht wirklich. Wir haben bis jetzt immer auf die propietären Protokolle gesetzt, wie Hiper-Ring von Hirschmann oder Derivate von EKS (naja) und Phoenix (ok). Bei EKS hatten wir z.bsp. mal ein Firmware-Problem, dass unsere Leitrechner erst neue ARP-Requests ausführen mussten, wenn sich der Ring reinitialisiert hatte. Lauter so nette Dinge, die man nicht haben will

schaut dir mal die group by-Klausel an. Und dann machst ein group by kunde mit sum(preis).

partikel[] p= new partikel[100]; [COLOR="Red"]// array p instanziieren mit 100 elementen von partikeln[/COLOR] int r_vx=(r_ziel_x-r_start_x)/40; [COLOR="#ff0000"]// 40.teil des x-vektors, wozu benötigt, evtl. später zu sehen[/COLOR] int r_vy=(r_ziel_y-r_start_x)/60; [COLOR="#ff0000"]// 60.teil des y-vektors, kein Z also 2D[/COLOR] int r_x=(r_ziel_x); [COLOR="#ff0000"]// X-Vektor oder banal gesagt Koordinate[/COLOR] int r_y=(r_ziel_y); [COLOR="#ff0000"]// Y[/COLOR] int t_x; [COLOR="#ff0000"]// \[/COLOR] int t_y; [COLOR="#ff0000"]// - lokale Temp Variablen[/COLOR] int t_r;[COLOR="#ff0000"] // /[/COLOR] Color t_c; double ent=Math.random();[COLOR="#ff0000"] // "zufällige" Zahl mathematisch zwischen [0..1) im rellen Bereich[/COLOR] if (ent<0.33) { t_c=new Color(205+(int)(Math.random()*50),0,0); [COLOR="#ff0000"]// zufällige Abstufung von relativ rot bis rot[/COLOR] } else if (ent>0.67){ t_c=new Color(0,205+(int) (Math.random()*50),0,0); [COLOR="#ff0000"]// zufällige Abstufung von relativ grün bis grün[/COLOR] } else { t_c = new Color (0,0,205+(int)(Math.random()*50)); [COLOR="#ff0000"]// zufällige Abstufung von relativ blau bis blau[/COLOR] } [COLOR="#ff0000"] [/COLOR]// Schleife über das array, sollte aber besser for ... i<p.length lauten for (int i=0; i<100; i++) { p[i] = new partikel(r_x, r_y, r_vx, r_vy, [COLOR="#ff0000"]// instanziieren des jeweiligen Elements im Array[/COLOR] Math.random()*10, [COLOR="#ff0000"]// mit Zufallswerten[/COLOR] Math.random()*2*Math.PI, t_c); g.setColor(p[i].c);[COLOR="#ff0000"]// oben gebildete Farbe setzen[/COLOR] t_x=(int)(p[i].x-p[i].r); [COLOR="#ff0000"]// Ursprungs-Koordinate X minus Radius (also für zeichenroutine nach links schieben)[/COLOR] t_y=(int)(p[i].y-p[i].r);[COLOR="#ff0000"] // Y - Radius, also für Zeichenroutine nach oben schieben (vermute, Zeichenroutine zeichnen von außen)[/COLOR] t_r=(int)(2*p[i].r);[COLOR="#ff0000"] // Radius als Durchmesser[/COLOR] g.fillOval(t_x, t_y, t_r, t_r); [COLOR="#ff0000"]// ausgefüllte Ellipse bilden (hier speziel Kreis, weil zweimal t_r als Radius)[/COLOR] } [COLOR="#ff0000"]// verschachtelte Schleife läuft 50mal über alle 100 partikel und wartet dabei pause(50)[/COLOR] for(int i=0; i<50; i++) { [COLOR="#ff0000"]// pro i über alle 100 partikel[/COLOR] for(int j=0; j<100; j++) { g.setColor(Color.BLACK);[COLOR="#ff0000"] // schwarze Farbe als aktuelle auf Grafikzeichenfläche setzen[/COLOR] t_x=(int)(p[j].x-p[j].r); t_y=(int)(p[j].y-p[j].r); t_r=(int)(2*p[j].r); g.fillOval(t_x, t_y, t_r, t_r); [COLOR="#ff0000"]// das ist die alte Stelle und hier wird das alte farbige Partikel schwarz überzeichnet[/COLOR] p[j].move(); [COLOR="#ff0000"]// jetzt wird das Partikel irgendwohin bewegt, wahrscheinlich nur ein bissl verschoben[/COLOR] g.setColor(p[j].c); [COLOR="#ff0000"]// jetzt wird wieder die ursprüngliche Farbe gesetzt[/COLOR] t_x=(int)(p[j].x-p[j].r); t_y=(int)(p[j].y-p[j].r); t_r=(int)(2*p[j].r); g.fillOval(t_x, t_y, t_r, t_r);[COLOR="#ff0000"] // und an die neue Stelle farbig gezeichnet[/COLOR] } pause(50);[COLOR="#ff0000"]// wahrscheinlich 50 Millisekunden warten[/COLOR] } r_ ist wahrscheinlich der Richtungsvektor, der von einer anderen Stelle übergeben wird. Die beiden Absätze die folgen sind: - einmal eine Schleife über alle 100 Elemente, wobei diese Partikel zufällig initialisiert, positioniert und das erste mal gezeichnet werden - und der zweite Absatz zeichnet 50mal wahrscheinlich alle 50ms eine Veränderung der Funken nach einer Positionsverschiebung auf eine schwarze Zeichnenfläche das vorher gezeichnete Objekt schwarz übermalen ist eine beliebte Methode um das Objekt von der Zeichenfläche zu "löschen" und nach Verschiebung wirds einfach neu gezeichnet. Und dann im nächsten der 50 Schritte dasselbe nochmal. Das ist ein sehr simple Animation

hmm, also ich konnte bisher noch nix gegen USB-WLAN-Sticks sagen. Hatte aber ehrlich gesagt beides von AVM. Würde das wahrscheinlich sogar an einem Desktop-Rechner bevorzugen, außer der USB-Port befindet sich dann im Funkloch

Ich hab mich ziemlich lange mit NTP und SNTP beschäftigt. Habe sogar selber einen Serverdienst für SNTP, Time und Daytime Protokoll entwickelt, weil nix vernünftiges zu finden war. Aber letztenendes ist jeder Windows XP Rechner gleichzeitig ein SNTP-Server. (SNTP, weil er kein "echter" NTP-Server wird ;D ) Also solange Deine Switche tatsächlich mindestens SNTP können, ist das Thema mit einem einzigen Windows XP Rechner und freigegeben Port 123 erledigt! Du musst Du dafür sorgen, dass sich die Switche auch korrekt und regelmässig aktualisieren, denn gerade das war bei vielen im INet vorhandenen Tools das Problem.

Hmm, ich dachte immer, die Kanäle 1, 6 und 11 würden sich nicht stören?! Hast Du andere Funknetze (Nachbar) im eigenen Bereich? Hast Du zum Beispiel Stahlbeton-Decken oder nen Teich dazwischen? (Deshalb bekomme ich zum Beispiel aus meinem Keller KEIN vernünftiges Signal eine Etage hoch, direkt oder schräg darüber) Schonmal einen konkreten WLAN-Analyzer reingehangen? Hat nicht die neue Fritz!Box auch so ein Feature?

Da solche Dienste ohne einen Clientanteil nicht möglich sind, ist eine große und möglichst einfache Verbreitung extrem wichtig. Allen anderen Leistungsmerkmalen voran muss der Dienst in allen "normalen" auf dem Markt üblichen Routern integrierbar oder vorhanden sein. Dann erst kommen Features, die der Service an sich bietet. Da würde ich zum Beispiel folgende nennen: - Einstiegsfeatures kostenlos, - Profifeatures kosten nicht viel, Einstiegsfeatures: - möglichst viele Domains, - daraus ergibt sich für ein Kundenlogin mehrere einstellbare SubDomains und oder Maschinen, - simples DNS (Name-Rec) auf den dyn-dns Eintrag zu einer IP (RDNS geht ja leider nicht) Profifeatures: - möglichst verschiedene TLD's, - weitere DNS-Records, wie MX, etc.

Um nicht gleich mit SAP ins Haus zu wackeln, kann ich Dir empfehlen zumindest mal eine komplexere Warenwirtschaft, wie beispielsweise NAVISION Financials anzuschauen. Kann ich nur empfehlen, habe mit Nav Fin selbst Kundenseitig programmiert.

Man spleisst die puren Fasern eines LWL-Kabel prinzipiell auf eine Spleissbox auf. Ich hab das noch nie anders gesehen. Maximal für kurze Strecken gibt es vorkonfektionierte Kabel, die kurzen davon werden zum Beispiel immer für das "Patchen" benutzt. Die "Spleissbox" ist gleichzusetzen mit dem Patchpanel bei CAT-Verkabelung. Steckervarianten und Kabeltypen kannst Du sinnig frei ausm Bauch entscheiden, wenn es keine Wunschvorgaben gibt. Ich würde empfehlen ein 8x2 fasriges LWL-Kabel zu verbuddeln und pro Gebäude eine Spleissbox reinzuhängen und alle Fasern auflegen. Dann entscheidest Du ob Du zur Sicherheit pro Strecke 4 Fasern für einen redundanten Ring benutzt. Wir benutzen für sowas meist Hirschmann, Phoenix Contact, EKS oder Moxa. Man kann aber auch eine sogenannte Linie mit jeweils 2 Fasern aufbauen, obwohl das auch als Sternstruktur verstanden werden kann. Es gibt aber auch Core-Switches oder Modulare Switches direkt aus der Netzwerktechnik, die bereits 2 LWL-Leitungen (wie bereits gesagt 2 LWL-Fasern pro Leitung) zu einem Ring vernetzen können. Haben da schon CISCO und HP eingesetzt. Das ist aber nur ein Schmankerl. Linksys (jetzt Produktreihe bei CISCO) ist aber großer Mist, Finger weg). Vorteil von den modularen Switchen ist ganz klar, dass die LWL-Ports direkt im Switch die volle interne Bandbreite nutzen können, was über externe Geräte nicht immer optimal ist. Auch sind LWL-Umsetzer, die GBit-Bandbreite unterstützen "etwas" teurer Wichtig ist, Deine Spleissbox sollte möglichst an einem zentralen Punkt sein, von wo aus man ohne diverse Umwege den Rest mit Kupfer (min CAT5e) verkabeln kann. Mein Vorschlag: - Multimode (ober 50er oder 62.5er ist egal) LWL-Kabel K hat 8x2 Fasern K1-K16. - Gebäude G1 hat Spleissbox B1 und Patchpanel P1 sowie Switch S1. - K wird verlegt zwischen G1 und G2 und G3, je nach geografischer Lage, mit Reserveschlaufen alle 50m. - Pro Gebäude baust in einen Schaltschrank B ein und legst die Fasern auf (dazu später beim Switch). - Im Schaltschrank baust ein genügend großes P ein und einen dazu passenden S. - Pro Gebäude verkabelst Deine RJ45-Dosen mit einem Kupferkabel, wie bereits gesagt mit LSA-Plus legst das CAT-Kabel auf Dose und das andere Ende auf Patchpanel. - Daraus ergeben sich zwei physikalische Netzwerkbereiche, LWL-Bereich und CAT-Bereich. - Jetzt verbindest die Ports des Switch mit kurzen Patchkabeln auf das Patchfeld. - und die notwendigen 2 Fasern pro LWL-Port mit dem Switch. - das Gebäude in der Mitte der Verkabelungslinie sollte eine doppelt so große Spleissbox bekommen, dann kannst Du das Kabel somit (umgangssprachlich ausgedrückt) komplett auftrennen und die Fasern der beiden Endstücke somit noch variabler verbinden. Fertig, der Rest ist Protokollseitig einzustellen.

Nein, leider ist mir kein Update in dieser Richtung bekannt. Auch stellt sich mir die Frage wie die Java Runtime das Hostsystem komplett "freezed". Das ist mir neu. Werden eventuell hostsystemabhänginge Bibliotheken über JNI (Java Native Interface) eingebunden, die das Problem auslösen? Ist der Softwarehersteller in der Lage Support zu liefern? Ich schlage vor, einen Testclient mit dieser JRE-Version einzurichten oder besser mit der dazugehörigen JDK-Version und die Anwendung ab Start zu analysieren. D.h. die im Bytecode direkt vorliegenden Classes (oder aus dem JAR-File). Startet man die JAVA-Runtime mit diversen internen Parametern, kann es nach Updates auch zu Problemen führen. Siehe -XX Parameter. Ohne konkretere Infos zum Aufruf und Software kann ich leider nich mehr dazu sagen.

8x2 meinte ich 8 Faserpaare, damit man Reserve im Kabel hat, weil Erdarbeiten um das Kabel zu ziehen/verlegen sind teuer Wenn Du alle 8x2 aufspleisst, kannst selber ausrechnen, was für ne Spliessbox Du dann benötigst. Aber ob unbedingt alle unbenötigen Fasern aufgespleisst werden müssen, weiss ich nicht. Hab ich selbst noch nie gemacht. SC oder ST, das is ne Glaubensfrage Ja, wenn Du 13 RJ45-Anschlüsse willst sind das 13 Patchkabel. Ich glaub es gibt auch Doppelkabel, spielt aber keine große Rolle. Die gebräuchlichen Größen für Switche sind 8,16,24,48,... Welche und wieviele musst Du Dir im Netzwerkplan überlegen, weil das eventuell davon abhängig ist, ob da eventuell Server stehen, nur Clients, ... Vielleicht lohnt es sich die RJ45 auf 2 Switche zu splitten, einen wichtigen mit LWL und unterlagert (eventuell auch in Linie) einen weiteren (kleineren) für unwichtigere Clients.

Hi, schau mal hier unter Lösungsansätze: Datensicherheit bei USB-Geraeten Und hier: Gruppenrichtlinien - Übersicht, FAQ und Tutorials Hoffe, das hilft Dir weiter.

3 Spleissboxes wirst Du definitiv benötigen. Reserve Teil 1: Auch kann ich nur empfehlen, lieber ein 8x2 LWL-Kabel zu verlegen. Denn dann zieht man nur ein Kabel und hat automatisch genug Fasern auf Reserve um a) eventuelle weitere Gebäude anzubinden oder bei Faserbruch auf andere Fasern auszuweichen oder c) zur Sicherheit einen Ring aufzubauen. Reserve Teil 2: Soweit ich weiss, verlegen unsere Subs auch alle paar 100m ein paar Meter als Zugreserve, wenn man an diesen Stellen evtl. später aufschneiden und spleissen will. Betrachten würde ich in Deiner Liste/Kalk zwei Bereiche: 1) LWL-Kabel -> Spleissbox -> Switch mit 1x besser 2x LWL und x-mal RJ45 2) 2fach Dosen -> CAT5-Verkabelung -> Patchfeld -> kurzes Patchkabel -> Switch aus Punkt 1) Anstelle des Switch aus 1) mit LWL gäbe es auch die Möglichkeit das auf 2 Geräte zu verteilen: 1x normalen Switch und 1x LWL-Koppler (aber das ist nicht der Normalfall). Bitte dran denken CAT5 ist bis 100m ok, alles drüber kann mit GBit bereits Probleme geben (Umgebungsabhängig).

Kein Problem, genau die 4 Seiten hängen bei mir an der Bürowand

Umso besser, dann kannst verallgemeinern und pauschal sagen, zu überbrückener Leitungsweg größer 100m (Reserve und keine Luftlinie ), dann LWL, ansonsten Kupfer. Ich denke mit dem was Du bereits weisst, kannst Deine Liste doch mal posten. Wir können die dann - falls notwendig - vervollständigen und konkrete Punkte diskutieren.

hmm, ich weiss nicht ob es ein Vorteil oder Nachteil war, aber ich benutze mehr oder weniger nur die Infos von oose Innovative Informatik GmbHSoftware-EngineeringUML

Ich denke im Standard-JDK gibt es keine Funktion, die das bereits für Dich übernimmt. Ich habe mir bisher immer mit einer URL-Connection geholfen. Es gibt dafür diverse Beispiele im INet, aber das Prinzip ist immer identisch: man muss den HTTP-POST nachbilden. Mal mehr (simple byte orientierte Socketverbindung) mal weniger (Url("http://.../form.xyz").openConnection(). Beispiel ist hier: Sending a POST Request Using a URL (Java Developers Almanac Example)

Ich hoffe ich geb dir den richtigen Einstieg, ich bin kein Netzwerkprofi, bauen nur so ein Zeugs in Tunnel, etc LWL: - 2 Fasern pro Verbindung - 3 Faser-/Kabeltypen: MultiMode (MM) ein paar km, SingleMode (SM) viele km, POF (ich sag immer abfällig Plastekabel ) ~ 50m - Stecker gibts unterschiedliche Typen, SC, ST sind gebräuchlich - man brauch Spleissboxen (wie Patchpanels bei CAT-Kabeln) Du brauchst definitiv noch einen Koppler um ganz banal gesagt von LWL auf RJ45 zu kommen, aber die gibts wie Sand am Meer, mit redundantem LWL, mit Ring-Funktionalität, etc. Wenn Etagen weit voneinander weg sind, würde ich pro Etage an einer oder mehreren Stellen LWL-Kabel hochziehen und spleissen, ansonsten CAT5e.

Recht zu haben ist eine Erkenntnis nach der Analyse. Und wichtig ist nur die Analyse. Das mit der New-IO habe ich deshalb gesagt, weil: - das von Java der zu bevorzugende Weg ist oder werden soll, - es direkte Unterstützung für typische Probleme gibt (unterschiedliche Charsets, Pufferung) die direkt ineinandergreifen, - der Umstieg in asynchrone (non-blocking) Socket-Programmierung mittels Semaphoren dann nicht mehr so schwer fällt.

Ich hab Dir das mal für das New-IO package umprogrammiert. Als Grundlage (ohne Fehlerbehandlung): import java.io.IOException; import java.net.InetSocketAddress; import java.net.Socket; import java.nio.ByteBuffer; import java.nio.channels.SocketChannel; import java.nio.charset.Charset; public class TestClient { public static void main(String[] args) { try { Charset std = Charset.defaultCharset(); InetSocketAddress isa = new InetSocketAddress("192.168.178.107", 9999); SocketChannel client = SocketChannel.open(); Socket socket = client.socket(); socket.connect(isa, 1000); System.out.println("Connected to "+socket.getRemoteSocketAddress()); client.write(std.encode("Hello Server")); ByteBuffer bb = ByteBuffer.allocateDirect(8192); if ( client.read(bb) != -1 ) { bb.flip(); String str = std.decode(bb).toString(); System.out.println(str); bb.clear(); // unnötig, da keine while, sondern nur einmal if }// while read client.close(); } catch(IOException e) { e.printStackTrace(System.out); } } } Server: import java.io.IOException; import java.net.InetSocketAddress; import java.net.ServerSocket; import java.nio.ByteBuffer; import java.nio.channels.ServerSocketChannel; import java.nio.channels.SocketChannel; import java.nio.charset.Charset; public class TestServer { public static void main(String[] args) { try { Charset std = Charset.defaultCharset(); InetSocketAddress isa = new InetSocketAddress("0.0.0.0", 9999); ServerSocketChannel server = ServerSocketChannel.open(); ServerSocket socket = server.socket(); socket.bind(isa); System.out.println("Server started at Port "+socket.getLocalPort()); ByteBuffer bb = ByteBuffer.allocateDirect(8192); SocketChannel client = null; while ( (client = server.accept()) != null ) try { System.out.println("Incoming connection from "+client.socket().getInetAddress()+" @ "+client.socket().getPort()); if ( client.read(bb) != -1 ) { bb.flip(); String str = std.decode(bb).toString(); System.out.println("Recieved: "+str); client.write(std.encode("RCV_"+str)); System.out.println("Sent: RCV_"+str); bb.clear(); }// while read }// try finally { client.close(); }// while accept server.close(); } catch(IOException e) { e.printStackTrace(System.out); } } }

Habe grade Deinen Client getestet und eine Zeile eingefügt und siehe da, es funktioniert! wr.write("Hello Server"); wr.flush(); socket.shutdownOutput();