Krelay -> realmrelay -> client -> server
Proxy1 -> Proxy2 -> Client -> server
Did anyone experimented with this?
Why do I want to do this?
You can only add javascript plugins into notifier so if I would run it also through KRelay I could add more plugins..
Would this theoretically be even possible?
Should be possible if you assigned both of the proxies a different port but even then you probably shouldn't do it because you're just creating more delay between the client and the server.
Isn't there a greater chance of packets going 'bad'?
Originally Posted by iliketrainz
Isn't there a greater chance of packets going 'bad'?
no .
- - - Updated - - -
well yes, since realm relay is outdated AF
How are you going to have 2 proxies on the same port 2050?
I guess you could transfer the data from both of them to a new app that uses port 2050, and make those two not use ports 2050? idk.
Originally Posted by PKTINOS
How are you going to have 2 proxies on the same port 2050?
I guess you could transfer the data from both of them to a new app that uses port 2050, and make those two not use ports 2050? idk.
Use 2051 for Krelay for example?
client -> 2051 -> app forcing the traffic to 2050 -> 2050 -> server
Originally Posted by heroofpl
Use 2051 for Krelay for example?
client -> 2051 -> app forcing the traffic to 2050 -> 2050 -> server
You just want to process the incoming packets from both realmrelay and KRelay right?
Thought of this?
Have a master application that listens on 2050.
Have the master application constantly send all the request details to KRelay & Realmrelay, and have them processed, and sent back to the server.
This way you can have only one app listening on 2050 and use both KRelay & realmrelay?
So in theory it's great and all, but it would require some "hardcore KRelay & realmrelay modifying".
This is what I mean if you dont get it:
(modified proxy #1 and #2 don't connect to the server, they receive from the master app using computers resources, editing packets offline and sending to master, master sends to server)
Of course, listening to two ports should be easier, but this way is more efficient, assuming it's done correctly.
[SIZE="2"]
Originally Posted by PKTINOS
Gotta love that X button
[FONT="Century Gothic"][COLOR="DarkRed"]
Originally Posted by Alde.
[SIZE="2"]
Gotta love that X button
No minimize or maximize buttons diagram is fake he should be gased @PKTINOS
[FONT="Comic Sans MS"][COLOR="Black"]
Originally Posted by Alde.
[SIZE="2"]
Gotta love that X button
lol.
For your signature, at the time that I posted that, you couldn't play the game from the appspot, I downloaded the client and it looked like this
Do you see any scripts? I don't.
Originally Posted by PKTINOS
lol.
For your signature, at the time that I posted that, you couldn't play the game from the appspot, I downloaded the client and it looked like this
Do you see any scripts? I don't.
suck my fuck
Originally Posted by Alde.
suck my fuck
That's what I thought
I did this for a short while with zautonexus/realmbot.
My setup was:
the client connects via port 2050 to zautonexus.
realmbot is listening on another port, lets call it 2051.
zautonexus connects to localhost with port 2051,
then realmbot connects to the game server.
the tricky part about this is managing reconnect packets.
by default, a proxy's reconnect handler looks something like this:
on reconnect packet:
->set proxy address and port to reconnect packet's address, so the proxy connects to the right place
->change the reconnect packet's address to localhost
->change the reconnect packet's port to the proxy's listening port
->send packet to client
this ensures that the client always stays connected to the proxy and that the proxy connects to the right server.
so our networking structure looks like this:
client -> inner proxy -> outer proxy -> server
basically, you'd leave the inner proxy's reconnect handler alone (so long as it sets port and address as described above)
then you'd modify the outer proxy's reconnect handler to set the reconnect packet's port to its listening port, instead of hardcoded 2050 (as most proxies are)
so if we were to trace the path of a reconnectpacket:
server sends reconnectpacket with an address of a server and port 2050 to the outer proxy.
the outer proxy changes its connection address to the address given in the reconnectpacket, and its port to the port given in the reconnectpacket (almost always 2050), then sets the reconnectpacket's address to localhost and its port to its listening port(2051 in this scenario), and sends it to the inner proxy
the inner proxy sets its address and port to the ones given in the reconnectpacket (localhost and 2051), then sets the reconnect packet's address to localhost (no change) and the its port to 2050, then sends it along to the client.
there might be a few more packet handling things you'd want to change to decrease latency, and you'd need to be careful of compounded packet changes (inner proxy gets the last change on server packets and outer proxy gets the last change on client packets)
but that's the idea. Not as hard as you'd imagine, and no need for any external programs.
[QUOTE=PKTINOS;12199154][FONT="Comic Sans MS"][COLOR="Black"]How are you going to have 2 proxies on the same port 2050?
Two separate internet connections?
[FONT="Comic Sans MS"][COLOR="Black"][QUOTE=HeavyPettingZoo;12223547]
Originally Posted by PKTINOS
How are you going to have 2 proxies on the same port 2050?
Two separate internet connections?
No, the modified proxies dont listen on 2050, only the master application does.
Originally Posted by iliketrainz
