Wahrscheinlichkeitsfrage bei hashCode() mit modulo

[hdi]

Hi, beim Start meiner App öffne ich einen Socket, damit beim Start einer zweiten Instanz dies scheitert (Socket ist schon offen), und ich das Programm beenden kann, da nicht 2 Instanzen laufen sollen. Jetzt sollen aber nur 2 Instanzen dann nicht laufen können, wenn es die gleiche JAR war, d.h.

String path = new File("").getAbsolutePath();

liefert bei beiden das selbe. Da ich den Socket davon abhängig machen muss, dachte ich mir ich leite den Port von dem hashCode des Pfades ab. Da der Port ja nicht beliebig sein darf, muss ich sicherstellen dass der Wert 1) positiv ist und 2) im gültigen Wertebereich für Ports liegt. Für zweiteres nutze ich modulo, also das ganze sieht so aus:

/* get runtime environment path */
		String path = new File("").getAbsolutePath();

		/*
		 * Open a socket using a port derived from the database path. Exit if an
		 * instance with the same database is already running
		 */
		try {
			int greatestPort = 65535;
			new ServerSocket(Math.abs(path.hashCode()) % greatestPort, 0,
					InetAddress.getByName("localhost"));
		} catch (BindException e) {
			e.printStackTrace();
			System.exit(0);
		} catch (IOException e) {
			e.printStackTrace();
			System.exit(-1);
		}

hashCode() kann ja auch nicht zu 100% garantieren, dass nicht 2x das selbe rauskommt bei 2 verschiedenen Strings. Aber es ist ja doch so implementiert dass es "quasi-unmöglich" ist. So, nun meine Frage: Inwiefern verfälsche ich die Sicherheit von hashCode() durch das modulo? Ist das okay, oder seht ihr da evtl Probleme in der Praxis?

Dreist gesagt könnte ich es jetzt auch so formulieren: Wie würdet ihr dat machen, gebt ma' Code her aber zack zack (Falls ihr dieses Vorgehen für zu unsicher anseht)

 

[javimka]

Der Hashwert ist ja ein Integer, also gibt es 2^32 = 4 Mrd Möglichkeiten dafür. Wenn du diese Möglichkeiten Modulo 65533 = 2^65 (ungefähr) rechnest, vermindest du die Sicherheit um 2^16, also um das 65000-fache oder noch anders gesagt, es existieren nur noch die Wurzel an Möglichkeiten. Das hört sich jetzt schrecklich an, aber wahrscheinlich wird dein Programm, so toll es auch sein mag, nicht zig-1000 Mal gleichzeitig gestartet
ABER, statistisch gesehen wird jeder 65000 Versuch, das Programm doppelt zu starten gelingen.

Ich habe ehrlich gesagt keine Ahnung, wundere mich nur, ob du wohl Probleme bekommen würdest, wenn du dein Socket nun mit dem Port 80 starten würdest, der ja für HTTP vorgesehen ist, oder mit einem anderen Port, der von anderen Programmen benutzt wird.

 

[Marco13]

Ja, die ersten... ähm .. ich glaube 1024 Ports sind doch sowieso irgendwie "reserviert", und sollten nicht für eigene Programme verwendet werden?!

 

[Spacerat]

Also der Vergleich, ob da 2x aus dem indenischen Jar gestartet wurde mag ja mit [c]hashCode()[/c] gehen. Aber aus dem HC einen Port abzuleiten ist die weniger gute Idee, weil man so zufällig auf einem schon belegten Port landen könnte, auf welchem keineswegs eine Instanz deiner Software laufen muss (wie mein Vorredner schon sagt: z.B. HTTP-80). Ausserdem könntest du mit deinem Beispiel auch in dem Bereich landen (0-1023), in welchem du administrative Rechte benötigst, um ihn zu öffnen.
Ich persönlich würde (Prinzipiell kann jede Java-Anwendung solch einen IIP* gebrauchen) der Anwendung einen Port für allgemeinen Austauch mit anderen Java-Anwendungen und einen privaten Port implementieren und dabei die Ports keinesfalls "zufällig" vergeben.

*IIP: InformationInterchangePort

 

[hdi]

Danke an alle, und Spacerat, kannst du mir da noch etwas weiterhelfen? Wie meinst du das konkret? Wie kann ich denn zB die Info des Pfades von einer App in eine andere übergeben, ohne einen globalen Server mit RMI usw. Findet ihr den Ansatz mit dem Socket schon falsch? Ich hab das irgendwo aus Google gezogen mal... Im Prinzip benötigt meine Anwendung ja gar keinen Socket und sollte auch keinen Port belegen, das ist ne 100% Standalone Client-Anwendung. Das ist halt ein Workaround gewesen... (Was ich immerhin schöner fand als das jetzt über zB Lockfiles zu lösen, wobei man da bestimmt auch erstmal wissen muss wie man es wirklich richtig macht)

 

[Spacerat]

Diese Idee mit den Sockets ist ja meistens gut und schön, aber in deinem Fall dann wohl weniger von Nöten. Da würde ich doch lieber zu Lockfiles greifen. Natürlich mit der Auflage, dass der Lockfile die ganze Laufzeit über geöffnet bleibt, d.H. also: kein anderes Programm kann sie löschen, lesen oder beschreiben. Da kann man dann auch den HC für den Dateinamen verwenden.
Nur nebenbei: Die Sache mit dem IIP ist dann mehr oder weniger auch überzogen. Die Idee dazu lieferte mir AReXX, eine Scriptspache auf dem Amiga, mit welcher verschiedene Anwendungen lokal miteinander Kommunizieren konnten (ohne TCP/IP, Netzwerk und, und, und...). Ich vermute mal, das solch ein Mechanismus mit RMI realisiert werden kann. Aber WG: Für deinen Fall ziemlich überzogen. Eine Anwendung, die sonst nichts mit Netzwerk zu tun hat, sollte meiner Meinung nach auch nicht solche Ressourcen verwenden.

 

[Illuvatar]

Du könntest auch mal das hier anschauen. Da wird auch beschrieben, wie du mit der bereits offenen Applikation kommunizieren kannst (d.h., rausfinden ob beides die gleiche jar ist).

Apropos gleiche jar: [c]new File("").getAbsolutePath();[/c] muss nicht das Verzeichnis der jar sein! Wenn z.B. [c]java -jar foo\bar.jar[/c] ausgeführt wird, dann ist das Verzeichnis foo nicht mehr in dem oben erhaltenen Pfad enthalten.

Irgendwie über den ClassLoader kann man aber das tatsächliche File-Objekt der jar erhalten, das weiß ich noch... ich vergess nur immer, wie das geht

 

[hdi]

Danke, dein Link ist super! Zwar durchaus etwas umständlich und für mich wohl overkill, da Fehler jetzt nicht unbedingt in etwas "Schlimmem" enden können bei mir, aber dieses Framework zu haben ist ja doch ziemlich cool! Jetzt muss ich nur noch rausfinden was der echte Jar-Pfad ist, weil ich das dann in die Lock-Datei schreib. Werd mal mit dem ClassLoader rumspielen...