Jump to content

+Everyone

Members
  • Posts

    2
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

522 profile views

+Everyone's Achievements

I ordered some spaghetti with marinara sauce and I got egg noodles and ketchup. I'm an average nobody.

I ordered some spaghetti with marinara sauce and I got egg noodles and ketchup. I'm an average nobody. (2/54)

5

Reputation

  1. Eu havia esquecido de adicionar o script ao tópico. Já foi adicionado
  2. Com o crescimento de qualquer projeto, seja de MTA ou o quê for, cresce também a inveja de muitos e a preocupação dos principais concorrentes. É muito comum tentarem desacelerar e inibir o crescimento do outro perante o medo. O quê muita gente não sabe é que na maioria das vezes, os servidores não são derrubados por DDoS ou DoS. Ataques DDoS demandam grandes quantidades de dinheiro investido, e nessa guerra digital, vence quem tem a melhor infraestrutura, ou seja, quem gasta mais.. Mas se a maioria das quedas ou interferência nos servidores não acontecem por ataque de negação de serviço(o famoso DDoS), então onde e como eles são feitos? Em primeiro lugar, tem a talvez mais conhecida maneira de deixar algo instável: 1 - Flood É importante saber que existem vários tipos de floods, o mais fácil de identificar, é aquele flood por chat. Ele não é o único, existem floods que são um pouco mais complicados de identificar. O flood via chat é muito prejudicial ao servidor, portanto, é recomendável que cada jogador tenha um tempo definido entre as mensagens que podem enviar. Além do flood via chat, existe o flood por comando, que é possível fazer com qualquer comando que qualquer servidor tenha. Por isso, também é recomendável que exista um intervalo de tempo entre os comandos feitos pelo jogador. Principalmente os comandos verificados por ACL são prejudiciais ao servidor. Alguns comandos que com flood são muito prejudiciais são: restart, refresh. Mesmo que o jogador não tenha permissão de executá-lo, o servidor verificará toda vez em que ele digita esses comandos protegidos. Uma solução para isso é bloquear esses comandos por serial, assim, mesmo com o flood deles, o CPU do servidor será menos estressado. O bloqueio desses comandos por serial aliado ao tempo necessário entre um comando e outro, fará com que o servidor não fique sobrecarregado, gerando menores consequências. 2 - Scripts maliciosos Infelizmente pessoas que já tiveram bom nome na comunidade de MTA:SA no passado, acabaram perdendo toda a sua reputação e começaram a fazer o mau, disfarçada por vários nomes. Muitas vezes (deixando claro que não é em todos os casos) as pessoas vendem scripts compilados nos quais possuem códigos maliciosos para gerar estresse no servidor e atrapalhar a conexão, às vezes a ponto do servidor ser reiniciado automaticamente. Muitos desses scripts maliciosos funcionam perfeitamente, mas o código malicioso é acionado por algum comando. Então, você pode verificar os comandos existentes em cada script com o comando commands disponibilizado no nosso script logo abaixo. Existem também casos em que há um backdoor que possibilita o programador malicioso de quebrar toda segurança do servidor e fazer tudo o que está ao seu alcance. Pode ser: Redirecionar jogadores para outro servidor, criar um código o qual lhe dará vantagem no servidor, ganhar acesso restrito ao servidor, fazer ligações externas (com fetchRemote) afim de afetar o servidor com por exemplo, um vírus. 3 - Scripts mal otimizados Também é possível, e infelizmente ocorre com muitos servidores, de ter seu desempenho afetado por scripts mal otimizados. Muitos scripts da internet e não só eles, até scripts que o dono do servidor paga, pode afetar e muito no servidor (quanto mais jogadores, mais é afetado). Dependendo do código produzido, pode conter centenas e às vezes milhares de atualizações de ElementData simultâneas - o que afeta o servidor de modo que não há nem mesmo dedicado para intervir. Essa função em questão, é extremamente prejudicial tanto para o servidor tanto para o client, que é o usuário final - o jogador. Para saber se algum recurso está consumindo mais do que deveria, você pode utilizar o recurso IPB, que já vem com o MTA. Se você não tiver esse recurso no seu servidor, você pode baixá-lo dos resources oficiais do mta e colocar no seu servidor. Obviamente, não são só os ElementData's que podem prejudicar o desempenho do servidor. Um script pode ser mal otimizado por várias questões que englobam a programação. O ElementData foi citado por ser muito comum e muito prejudicial. Se você tem ou está montando um servidor, coloque além das suas idéias de novidades para ele, sua preocupação em relação ao desempenho de cada resource que irá rodar na máquina. Para saber como anda o desempenho dos resources no servidor, você pode verificar olhando o painel do resource ipb. Para isso, ligue o resource e digite o comando no chat "/ipb" ou no F8 "ipb". Selecione a categoria Server, alterne entre as opções de monitoramento e você saberá qual script está consumindo mais e afetando o desempenho do seu servidor. 4 - Múltiplos caracteres no login Talvez esse seja o mais bizarro dessa lista. Não limitar os caracteres no qual as pessoas podem escolher seu usuário ao se registrar. Isso, aliado ao flood de muitos logins com muitos caracteres, pode sim afetar o desempenho do servidor e até mesmo derrubá-lo. Esse é um exemplo de script com falhas deixadas pelo seu criador, que alguns servidores acabaram utilizando. E como não acaba aí, tem também códigos para fazer qualquer bom programador cair em desgosto que fazem aumentar muito o uso de cpu, de memória gráfica e ram. Problemas em geral por uma grande falta de preocupação do criador ou até mesmo a indiferença por ter aquela máxima "se está funcionando, tá bom" e "o que importa é terminar e receber meu dinheiro" (no caso de Scripter pago) acabam fazendo com que se proliferem péssimos tipos de scripts os quais muitos servidores grandes acabam utilizando. Link do script citado acima: https://community.multitheftauto.com/index.php?p=resources&s=details&id=18156 Também não posso deixar de agradecer ao @DNL291, que me ajudou a criar este tópico.
×
×
  • Create New...