Banana-Coding.com - Java Knuddels Emulator

Irgendwie stehe ich grad auf dem Schlauch.

Ich habe angefangen einen eigenen Clienten zu schreiben, nur irgendwie kriege ich das Handshaking nicht hin, da der Server das Paket komischerweise anders "intepretiert".

Ich verwende die Modifizierte Banana-Version von Bizzi.

Server-Log:

Zitat

Loading butler
Loading channel styles
Loading channels
Loading smileys
Starting FlashPolicyServer
Listening on port 2710 (Websocket: 2711)
p
Unhandled opcode: 'p'

Client-Log:

Zitat

init
\0
t\0V9.0bad\0http://localhost/index.php?page=chat&v=90bad2&c=0\08\01.7.0_04\0-\053741\0Java HotSpot(TM) Client VM\0-

Wie man der Log entnehmen kann, wird zwar das Handshake-Paket "t" gesendet, der Server empfängt das ganze aber irgendwie als "p".
Hab erst gedacht, dass es vllt. ein Charset-Problem sein könnte, aber im Gegenteil. Beide Applikationen laufen unter UTF-8. Ein forcen auf UTF-8 funktioniert hier auch keines weges (beispielsweise über new String(..., "UTF-8"); bzw. getBytes("UTF-8");)

Hat vielleicht jemand eine Idee? Source des Clienten ist angehangen.

Edit:
Ich habe nun mal im PacketBuilder den Cast von writeByte von char auf byte gesetzt, und bekomme Serverseitig nun folgende Log:

Zitat

Loading butler
Loading channel styles
Loading channels
Loading smileys
Starting FlashPolicyServer
Listening on port 2710 (Websocket: 2711)
New Client
New Client
[IN] pt0V9.0bad0http://localhost/index.php?page=
Unhandled opcode: 'pt0V9.0bad0http://localhost/index.php?page='

Das lässt darauf schließen, dass es wohl am Initalisieren der Connection liegt. Es wird ja normalerweise erst 0x00 Byte gesendet, um in den Client-Mechanismus zu gelangen, 0x02 wäre ja beispielsweise die die Registration.
Und ich glaub ich weiß nun auch, wie ich das ganze Löse. Ich gehe einfach hin und entferne getConnectionType() und setze einfach dies zuvor bei getHandShake() vorran. Mal testen...

Edit 2:
Selbst dies löst das Problem nicht.
Ich bekomme zwar nun die Channnel-List zurückgeworfen, da stimmt aber dennoch was nicht:

Zitat

Loading butler
Loading channel styles
Loading channels
Loading smileys
Starting FlashPolicyServer
Listening on port 2710 (Websocket: 2711)
New Client
New Client
[IN] q
[IN] t
5 Banana
( xyz Lobby
b Lobby
1 p B - Mafia
1 p B -
[IN] V
Unhandled opcode: 'V'
[IN] .0bad

War ja irgendwie klar, dass niemand dazu beitragen kann.
Hauptsache alles das downloaden und in die Finger bekommen, was nur geht.

Auch den von Bizzi?
Ich hab halt irgendwie Probleme Pakete zu dem zu senden, die kommen da irgendwie falsch an.

Edit:
Das verwundert mich halt, da ich die Protocol-Klasse sowie den PacketBuilder verwende und des direkt vom Server stammt. Huffman ist bei beiden Seiten disabled, des wollte ich später ggf. machen.

Ich glaube du bist am ganz anderen Ende.

Ich rede von einem Selbstgeschriebenen Java Clienten, nicht etwa den HTML-Clienten.

Werde ich morgen mal probieren, danke für den Tipp. Hab mein laptop beim Kollegen gelassen und hab die Source derzeit nur dort drauf

Die Frage ist aber, was denn daran falsch ist, wenn:

a.)
... out.write(new byte[] { 0x00 });
bzw.
... out.write(0x00);
b.)
... Des über den ohnehin servserseitig genutzten PacketWriter zusammengestellt wird
c.)
... Des direkt am Handshake-Paket vorran gestellt wird (also \0t\0,..).

Im Falle von Option C sollte das doch gehen, da ja ohnehin nur das erste byte gereaded wird und dann in den Mechanismus kommt, wo der rest gelesen wird?

OK, ich habs nun gecheckt. Bin wohl etwas zuviele Zeilen momentan am schreiben, und dann 1.000 verschiedene Projekte

Also nochmal.
Es ist schon richtig das NULL-Byte als erstes gewrited wird, um in den Mechanismus zu gelangen. Theoretisch "könnte" der auch direkt am Handshake-Paket vorangestellt sein - Aber jetzt kommt das "aber":
Nach den NULL-Bytes wird encoded/decoded.

Das Problem was ich also hab/hatte ist, dass auch diese NULL-Byte encoded wird, was der Server natürlich falsch intepretiert, da er den ersten Byte-Read eben unbehandelt checkt.

Es gibt also 2 Optionen:
A.) Wo der Typ gecheckt wird (type == 0x00) entweder zusätzlich noch decoden (also type == 0x00 || Protocol.decode(type) == 0x00)
B.) Einfach die Send-Methode erweitern: