Criei um projeto baseado no seu script e python (I created a project based on your script and python)
ThallesLazaro opened this issue · 13 comments
Olá meu nome é Thalles e eu fiquei muito feliz por achar seu script de servidor de gunbound, acabei mexendo no código e automatizando boa parte do servidor, ou seja, eu criei um projeto que você apenas liga o servidor e já esta pronto para uso, o pacote inclui também o client do jogo, o projeto eu também disponibilizei no github: https://github.com/ThallesLazaro/GunboundTH-Server-and-Game-Portable
Gostaria de te agradecer pois seu o seu repositório, o meu não seria nada, te dei os credito no meu repositório e vídeo no youtube.
Hi my name is Thalles and I was very happy to find your gunbound server script, I ended up tinkering with the code and automating much of the server, ie I created a project that you just turn on the server and it's ready to use, the package also includes the game client, the project i also made available on github: https://github.com/ThallesLazaro/GunboundTH-Server-and-Game-Portable
I would like to thank you because its your repository, mine would be nothing, I gave you credit in my repository and youtube video.
Hi Thalles,
I looked at your project, and I think it's great. Your effort in simplifying the deployment of the server will make it accessible to more people. Thank you for sharing your hard work, and I wish you success in your endeavor.
Olá Thalles,
Eu olhei para o seu projeto e acho que é ótimo. Seu esforço em simplificar a implantação do servidor tornará o jogo acessível a mais pessoas. Obrigado por compartilhar seu trabalho árduo e desejo sucesso em seu esforço.
Hi there!!
First of all thanks for the hard work you guys did.
I know there is a long time we don't update this repo but I'm wondering if I still can have some points regarding tunneling and services.
I've tried to deploy it publicly (Amazon, Heroku, cloud services etc) but I'm currently facing a unexpected behaviour after joining a game room: locally everything works perfectly and very straightforward, but when it turns to public IP it calls SVC_TUNNEL several times leading it to be unplayable after the room creation.
Would you mind to help me to figure it out?
Best regards,
Gabriel Fraga
Sorry @jglim i forgot to mention that me and @ThallesLazaro are working in pair to make it happen publicly, that is the reason I've replied to this thread
Hi Gabriel,
The client is based on a peer to peer design, and prefers to communicate with a peer directly whenever possible. When a direct connection fails (firewall, NAT, or issues with the server implementation), the client will send a SVC_TUNNEL request through the server to relay its messages to the destination peer.
This is as far as I remember (been a while), and if the network isn't an issue, perhaps both of you might want to investigate the server's p2p implementation if it is broken or confusing LAN/WAN addresses/ports or something like that.
The other option is to figure out and implement the tunnel packet relaying, which is probably better in the long run especially from a privacy perspective.
I don't have the capability to look into this issue in depth, but I hope this nudges both of you forward.
I don't have the capability to look into this issue in depth, but I hope this nudges both of you forward.
Hello @jglim and thanks for the rapid response.
Unfortunately it is beyond my skills both fixing p2p/tunnel or packet replaying implementations.
Our discoveries so far was that when any peers try to communicate to each other through a public IP then it is where the problem resides. Locally everything works as expected.
I was going to the tunnel packet replaying path but i have no idea how those bytes/hex values are sent/handled between client and server. When we receive the 0x4500 command i have no idea what to do with the data sent.
@kaapiel Você ainda está trabalhando neste projeto? Conseguiu alguma resposta sobre o tunnel e etc? Também estou enfrentando alguns problemas em relação à ele
@kaapiel Você ainda está trabalhando neste projeto? Conseguiu alguma resposta sobre o tunnel e etc? Também estou enfrentando alguns problemas em relação à ele
Falo por mim, depois de algum tempo sem sucesso, acabei desistindo sobre esse problema, não conseguimos desvendar o problema hahahaha, mais caso alguém tenha sucesso por favor nos fale Hehehe.
@ThallesLazaro Você tem discord ou algum outro meio de comunicação?
Bom dia.
Quais as dúvidas atuais sobre o tunnel(SVC_TUNNEL)? Tenho certo avanço no pacote e posso apoiar com o que sei.
Good morning, which questions do you guys have regarding tunnel(SVC_TUNNEL)? I may help with the knowledge I've collected so far
Bom dia, Castro, tudo certo?
Eu entendi que o cliente envia o packet do tunnel para o server, o server descarta os dois (ou três) primeiros bytes e envia, no lugar desses bytes descartados, o slot_room do cliente que enviou o packet, junto com o restante dos dados para os ocupantes da sala.
Na sala de espera isso me funciona relativamente bem, a comunicação rola de boa, porém quando inicia a partida algum problema acontece e os turnos não fluem. Ou o jogo trava, ou os dois jogam ao mesmo tempo (e o tunnel não funciona porque não se comunicam), somente o chat segue funcionando. Se puder me dar uma luz quando à isso agradeço
Olha, se o chat funciona, então a lógica-base do tunnel está correta, visto que em geral o chat é feito pelo tunnel na sala de espera e ingame. Não há muito mistério no tunnel, já que o mesmo é literalmente uma maneira de corrigir possíveis erros na comunicação p2p. Caso o tunnel funcione na sala, porque não funcionaria ingame?
Só que além disso, o tunnel também deveria ser responsável por algumas coisas in-game, e principalmente ser responsável por basicamente qualquer comunicação p2p que falhe (ou seja, quase tudo que acontece dentro do jogo e que não funcione pelo p2p) O TH não deveria precisar muito do tunnel ingame para grandes coisas além de chat. O que vocês descrevem parece ser um erro quando o TH tenta utilizar o tunnel ao invés do p2p tradicional. (mas não faz tanto sentido assim ao meu ver, visto que o chat é funcional e o mesmo usa o tunnel)
Antes de tentar ajustar todo o tunnel, recomendo verificar o client TH utilizado em si. O que vocês descrevem não parece ser ncessariamente um erro desse projeto do servidor em si, visto que o p2p deveria evitar que o tunnel seja ativado, e o tunnel funciona em outras ocasiões.
Vocês tem certeza que é uma má implementação do tunnel que está causando isso?
Caso seja mesmo o tunnel, é necessário debugar os pacotes com algum packet sniffer e verificar o que está rolando no lado do client e entender a partir de quais pacotes o servidor começa a tomar atitudes inesperadas.
Se faz necessário um debug a fundo, verificando quais pacotes estão sendo enviados via tunnel, se deveriam mesmo estar sendo enviados (estão sendo enviados por falha no p2p?), e se o servidor está os redirecionando adequadamente.
Uma vez que são redirecionados, não há porque não funcionar.
Entendido, Castro, muito obrigado pela explicação. Estarei verificando mais a fundo todos os passos que citou acima.
No meu caso em específico estou adaptando essa source para rodar o cliente season 3 versão 832 do server Brasileiro. Creio que devam haver algumas diferenças significativas para o TH.
Essa source não vai funcionar no Season 3. O tunnel também é provavelmente diferente no season 3, mas não tenho conhecimento profundo sobre.
Sei que no season 3 há tantos itens extras que provavelmente todos os pacotes-padrões são bem maiores.
Você precisará de um debugging mais profundo, se quiser, depois abra uma issue sobre.
Acredito que GRANDE parte desse código em python precisa ser modificado para o season 3, pois no season 3 há uma gigante diferença na comunicação dos pacotes e no tamanho de cada um dos pacotes ao se comprar com o TH.
Ainda assim, é um belíssimo trabalho, caso seja open-source e livre para uso por qualquer pessoa, eu gostaria de ajudá-lo.