arfneto

@André T Franco eu demoro para entender. Ainda não ficou claro para mim se o que quer alterar é esse arquivo texto que está mostrando, ou o arquivo original que esse troço representa. Afinal como está são 3 caracteres para cada byte de algo que já existia com 1 só. " 40" é a mesma coisa que @ por exemplo. De todo modo a maneira comum de fazer isso é escrever um editor, online ou via arquivo, e usar um flltro. Por exemplo um arquivo assim @c000 + 8 32 @c000 - 12 @c000 + 0 + 40 podia ser tratado como: mudar o valor para o oitavo byte depois de @c000 para 0x32 apagar o que estiver 12 byes depois de @c00 inserir 0x40 a partir de @c000 E o programa x seria usado assim: x entrada,txt comandos.txt saida.txt e se o cara usasse só dois parâmetros criaria o arquivo de saída com o mesmo nome. Não poste uma imagem de um texto... Não ajuda nada. Poste o texto numa caixa de texto. Assim alguém que quiser ajudar terá mais facilidade em copiar TEXTO e seguir adiante. Uma imagem de pouco serve e talvez seja pedir muito que alguém crie um arquivo para depois testar o seu problema sem o seu programa. Ou com essas 10 linhas de programa que postou. @FFC2 AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD AA BB CC DD

@Felipecfk ? Não, não é 40.0x20 ou 32 em decimal é o espaço. 0x40 é '@' Já te perguntei isso e não respondeu. O que é uma "imagem de arquivo" ??? Quer mudar esse texto aí que mostrou ou isso aí é um DUMP do arquivo original? De todo modo não é nada comum mudar direto no arquivo. Pode abrir como entrada e saída sim, modo "r+" e regravar o que quer. Ao gravar deve efetivar as alterações antes de ler de novo. Essa é uma das razões de chamar fflush, e não aquela bobagem comum de "limpar" o buffer, já que fflush sequer está definida para entrada. Mas o comum é gerar outro arquivo para ter algum nível de segurança, e trabalhar com partes do arquivo na memória.

@guveron Não vai fazer diferença. São passivos. Quer tirar a dúvida? apenas troque um pelo outro por alguns minutos, ou leve um terceiro switch e use primeiro no lugar de um depois no lugar do outro, o simples.

wifi nada tem a ver com dhcp nem com IP. Apenas ethernet. Uma vez que a conexão wi-fi (wi-fi é ethernet) esteja estabelecida os dois PC (sem plural, PC é Personal Computer), cada equipamento envia um broadcast na rede procurando por um servidor de endereço (DHCP). Qual a máscara de rede em uso? Não dá pra saber se os endereços estão em redes distintas sem saber a máscara de rede. E a partir daí pode ter servidores DHCP oferecendo endereços em redes distintas, e a latência vai determinar qual oferta --- DHCPOffer --- vai ser aceita primeiro. Por isso é preciso saber a máscara de rede.

@guveron switches passivos não requerem nenhum tipo de configuração. Basta trocar. Deve descartar os que tenham alguma porta com defeito. É difícil saber o quanto esse defeito afeta a comutação dele em geral e pode interferir no desempenho de tudo.

Está mesmo lendo um arquivo texto com esses dados ou o que está mostrando é um DUMP de um arquivo binário? Isso usa 3 caracteres por byte mesmo? Exceto pelos headers @b1b2...

A norma para esses cabos para conexão gigabit é de 99. Cat5E de enhanced. Ainda na tal década de 90. E já havia rede gigabit, só não era assim popular. Era normal rede a 1 e 10mbps durante os 90. Muitas vezes usando cabos coaxiais com conectores BNC e não xTP (par trançado). Não por acaso 100mbps até hoje é chamada de Fast Ethernet, porque a normal era a 10. Nem TCP/IP estava estabecido nessa época. X25 era muito usado, via linhas dedicadas e mesmo par trançado de 2 fios, o popular telefone. E com um modem enorme em geral da 3COM ou US Robotics. Nessa época provavelmente não eram não. Mas pode ver em geral uma inscrição na lateral do cabo, com a categoria e talvez a frequência. Mas entenda que o cabo é uma coisa e o patch cord é outra. O que a norma busca garantir e nas normas para certificar os fabricantes é o cabo, da infraestrutura, mais o cabo de rede, esse curtinho com as duas pontas --- o tal pach cord --- atingirem um certo alcance para uma certa velocidade. Em geral 95+5 metros. Para o cabinho de 1m a realidade é outra. E é isso que o provedor trás. Uma conexão direta do aparelho deles com o seu computador. Por exemplo no Mac Mini um cabo Cat5E alcança 5 gigabits fácil. Até uns 10/15m pode até ficar estável até em 10 giga se o ambiente for normal. Mas se estiver falando em uma rede comum para garantir 10G até o rack a história é outra. Da documentação da Apple: É só um exemplo. Precisa considerar que FE é a 4 fios. E então haviam cabos naquela época que só tinham 4 fios. E os que tinham 8 muitas vezes eram usados para rede e telefonia. Não por acaso o conector RJ11 --- telefone --- encaixa certinho no soquete de rede RJ45 --- rede. Os pinos 4 e 5 foram separados para isso, E na norma se usam os fios azuis. E se tem um KS, aqueles telefones antigos tipo da série 24H, da aT&T, eles usam 4 fios e aí entram os pinos 7 e 8 e os cabos em marrom. Com CAT5E e adiante se passou a usar todos os 8 fios e aí adeus a ideia de passar um telefone e um ponto de rede com um cabo só para a mesa de cada um. 5 ou 5E? E fala do cabo mesmo, passando pela parede até um soquete onde vai plugar o clabo de rede? Ou só do patch cord para ligar direto no roteador da operadora? Ainda o mesmo caso: se usar isso dentro da parede vai gostar de terem blindagem adicional e muito de serem flexíveis porque vai gastar muito menos tempo e dinheiro para passar pelos dutos. E se forem mais frágeis que o AWG24 de cobre pode não ser o fim do mundo já que não há tensão mecânica dentro das paredes. Apenas faça os patch cords com um cabo melhor: os usuários por exemplo costuman atropelas cabos de rede com rodízios de cadeira, com gavetas, torcer dentro de maletas girando o pulso, como se vê toda hora em escritórios cabos de rede totalmente torcidos. Cabos CAT6 7 e 8 são pouco flexíveis, em comparação. E muito mais grossos. Pode ser um pesadelo ou a simples razão de usar fibra ótica às vezes. O cabo 6 ou 6E tem uma canaleta em X de plástico DENTRO do cabo. É muito mais difícil de passar pelos dutos de sempre, 3/4". E cabem menos cabos claro. Tem que considerar tudo isso. Pois é. Se tiver defeito em um dos fios 4 5 7 8 não vai ter conexão a 1000, mas vai ter FE. Agora se tiver falha nos pinos 1 2 3 e 6 não vai ter conexão nenhuma. Considere usar conectores pass-thru, de passagem. Com esses você terá muito mais sucesso se não tem experiência. E pode prender até com uma chave de fenda... Como esses ao lado. Assim garante que não há inversão de pinos e que não faltou ninguém. Para os soquetes de parede tem uns de gilhotina da Pial ou da Schneider que prende só com uma chave de fenda e não precisam de ferramentas especiais. E uns de pressão que não usam ferramenta nenhuma, só a guilhotina.

@Ma458noel talvez deva comprar para o proximo cliente $180 mais impostos por 250ft Cat8 que não se encontra aqui pode ser interessante 1000f de Cat7 ou superior da VOKA por $5000 é mais difícil de aceitar.

@Diogo Morais como eu disse, mesh não aumenta o alcance: aumenta a cobertura. O alcance é menor, mas você compra outros POD -- o nominho fancy que o marketing arrumou para eles. Por outro lado, solução é o que resolve. E no caso de mesh prefira SEMPRE os que permitem ligar o canal de controle --- chamado de backhaul --- via cabo. E não via rádio, porque é um contra-senso.

@Alvaro José Masiero agora faz mais sentido. Entenda que DHCP nada tem a ver com o wifi ou SSID: é só um broadcast a mais na rede. wifi nada tem a ver com IP. Dependendo da latência você pode ser atendido por outro servidor DHCP e foi isso que eu perguntei tempos atrás: se quando demora quem responde é outro servidor e não o mais "próximo". E não disse nada sobre os `tempos de Lease desses servidores. Usa o mesmo tempo ao menos? Seus clientes mudam muito? Entenda que se usa intervalos muito grandes pode facilmente esgotar endereços em algum deles se tem muita rotatividade. DHCP usa 3 ou 4 mensagens só. Mude o Lease para uns 10 minutos EM TODOS e teste. Pode ser só isso o problema. É a mesma razão pela qual grande parte dos bares e restaurantes que oferecem wifi aqui sempre me diz que o wifi trava na hora do almoço e tem que desligar e ligar de novo pra voltar Não tem, mas claro se desligar volta com todos os endereços disponíveis...

@Alvaro José Masiero É difícil entender só com o que você explicou, e não entendi a solução que marcou. De todo modo entenda que esses endereços que mostrou, 192.168.1.50 / 100 192.168.1.200 / 254 192.168.1.101 / 150 São endereços de host e não endereços de rede. E estão todos na mesma rede. E esses /100 /254 e /150 seriam o que? Em geral essa é a nomenclatura para subnet, mas essa rede classe C 192.168.1.0 só tem 24 bits para endereço, com o total de 254 hosts. O DHCP está onde? Qual o tempo de validade do endereço? Tem um servidor só? E parece, a julgar pelo desenho, estar misturando wifi com ethernet. wi-fi é ethernet, assim como o cabo. A rede sem fio, no entanto, nada tem a ver com IP, que roda acima da camada ethernet. Pode ter várias redes wifi operando nesses AC1900 ou em outros AP, usando DHCP servido por outros roteadores, ou computadores em sua rede.

Tempo de Lease sempre existe. Talvez esteja confundindo isso com o tempo de resposta do servidor. Se não precisa dessas redes isoladas, e acho que já sabe de alguns problemas que isso traz, fora o múltiplo NAT e confusão na LAN, a melhor performance vem com uma única rede IP, DHCP ativo em todos os roteadores para diminuir a latência, não usar nenhuma porta WAN exceto no link da.... WAN.

Escrevi errado. Estão ligados via WAN e não é boa ideia. Vai ter redes isoladas e uma boa perda de performance, em troca de ter algum isolamento entre as redes. E precisar de rotas entre elas e ter muitos outros problemas de conectividade, como como impressoras de rede e servidores de arquivos. O serviço DHCP em qualquer um desses pontos deveria reponder em 5/10s. Qual o tempo de lease do DHCP? Tem muitos perif'éricos ligados nessas redes? Testou sem nada mais ligado a um deles, apenas via wifi e depois LAN com o wi-fi desligado? DHCP envolve apenas alguns broadcasts. Tem mais switches nessa rede?

Então os 3 estão ligados via LAN ao roteador principal e não é algo que dê boa performance. Mas nada tem a ver com DHCP. Se estivessem na mesma rede a latência de 1 ia fazer com que algum outro respondesse antes. Não tem nada na rede que interfira em broadcasts? Usa blacklists, whitelists, essas coisas? Algum desses antivirus que interferem com a rede?

Talvez devesse continuar postando o código, de modo que alguém possa ajudar. Qual foi a dificuldade em salvar? É muito simples manipular arquivos em C. Essa linguagem foi criada para acelerar o desenvolvimento de um sistema operacional --- Unix --- em que tudo é arquivo. Tudo, memória, dispositivos, processos... E assim não poderia ser difícil. Escreva em torno dos dados. Programe em torno dos dados. O que vai salvar é apenas o score para o jogador. E a partida tem resolução instantânea. Não entendi porque precisa de uma função "bot" O código no github continua com quase todos os problemas que te apontei. E difícil de ler e alterar. Entenda que é normal ter um switch dentro de outro. Um menu de uma opção só? Para que? Faz diferença ocultar o cursor?

Demora nos 3 roteadores e acaba entregando endereços na rede de cada um? ou demora e acaba recebendo de algum dos outros? Deve testar isso

powerline gigabit é caro e difícil de achar mas seria uma opção. mesh não é para aumentar o alcance. Na verdade diminui. A potência das antenas é menor porque a ideia é justamente essa: aumentar o número de antenas --- chamadas POD pelo marketing --- e diminuir o alcance para reduzir a interferência entre as redes. Se sua casa tiver um layout convencional dessas construídas nas últimas décadas, ou em especial apartamentos, terá um ponto de telefone e outro de antena no seu quarto e na sala, e um duto lá para passar um cabo 5E. Aí você passa um cabo pro quarto e um pra TV. Os caras da operadora sempre colocam o modem do lado da TV mas nunca põem um cabo. E TV gasta muita banda hoje em dia. E aí fica com o wifi apenas para o que precisa mesmo. Com os 500 reais pode usar um roteador de 3gbps bacana no quarto, e ligar outra TV via cabo ao lado do segundo roteador, junto ao micro. Os dois roteadores ligados via LAN, sem perdas e com uma rede IP só.

@Mega Blaster não sei dizer. E de todo modo firewalll é proxy conceitualmente. E se tiver um micro lá parado pode usar direto o fw do Windows. Proxy. Squid, Linux, routerOs, tudo isso resolve mas envolve mais conhecimento

Solução Cabos em São Paulo tem esse cabo da alemã VOKA VOK XLAN1000 S-FTP CAT7 4X2X23AWG-1 BTE PT da VOKAN que pode te servir. Até 1000hz. Custa em torno de 27.000 reais. Por outro lado na amazon pode pedir esse (até 2Ghz cat8) Despacham para o Brazil e vai custar perto de $500 no final. Veja que são só 250ft, um quarto do que vem nas bobinas comuns. Até 40G.

@TioJota Não tem mesmo um firewall na rede? Não pretende implementar um? Numa rede pequena pode ser só uma máquina qualquer rodando Windows com o firewall e duas placas de rede... Como eu disse, o mais simples é usar um gateway que não vá pra lugar algum. Assim esses 4 micros navegam ok na rede mas qualquer acesso a outras redes vai falhar. Pode usar isso direto em um simples script de login nas contas que usam essas máquinas. Ou definir as configurações de rede para elas separadamente (menos conveniente se não tem acesso permanente ao local

Acho que sabe o que está errado agora, como @devair1010 te explicou. Entenda que o comando switch tem uma cláusula default que você deve se acostumar a usar. E entenda também que na falta de um break o código continua rodando pelos comandos abaixo. Isso costuma "pegar" muitos iniciantes. Veja esse programa #include <stdio.h> int menu(int opcao); int main(void) { for (int op = 1; op < 6; ++op) { printf("vai usar opcao %d no switch\n", op); menu(op); } return 0; } int menu(int opcao) { switch (opcao) { case 1: printf("1\n"); break; case 2: printf("2\n"); break; case 3: printf("3\n"); case 4: printf("4\n"); break; default: printf("outra opcao: %d\n", opcao); break; } return 0; }; E a saída vai usar opcao 1 no switch 1 vai usar opcao 2 no switch 2 vai usar opcao 3 no switch 3 4 vai usar opcao 4 no switch 4 vai usar opcao 5 no switch outra opcao: 5 E entenda as diferenças. Use o computador para essas coisas e aprenda a escrever simples programas de teste ANTES de escrever um programa inteiro Sobre o código na pergunta Seu programa não está ainda bom. Pode ser que consiga concluir desse modo, mas ele tem muitos dos problemas comuns que aparecem aqui no forum e em outros, acho que pela maneira como ensinam isso nesses tempos. Eu tenho uma lista e então vou apenas repetir alguns dos itens Não use acentos em nomes de variáveis ou comentários. Evite mesmo em strings a menos que o enunciado exija. Não vai aprender nada e só vai ter problemas. Mais ainda evite usar Unicode e coisas como emojis. Nada acrescenta ao código e não sair em muitas telas, ou vai sair outra coisa. E se imprimir o programa pode não sair nada ou algum lixo. Evite comentários como "main é a função principal" ou "declaração de variáveis" ou coisas óbvias desse tipo. Comente o porque está fazendo algo, escreva para você mesmo no futuro, tipo daqui a 2 dias quando pode não lembrar para que era aquele ponteiro, por exemplo. Não use system() para nada. Não estará fazendo nada. Não estará aprendendo nada. Não há praticamente nada que possa fazer com system() que não possa fazer em C ou C++. system() foi escrita em C e o sistema quase todo também. E em geral é proibido em empresas e escolas afinal: é um risco grande de segurança. E se tem algo que você não possa inicialmente fazer em C ou C++ talvez não deva mesmo fazer. main() deve ser a primeira função de seu programa. Se possível em um arquivo separado. Há muitas razões para isso, mas em especial vai gostar de começar a ler seus programas e os de outros a partir de main() E a partir do início do texto. Ao mesmo tempo. E ao usar protótipos fica trivial passar as declarações todas para um arquivo .h que é o mais prático afinal. evite retornar void de funções: em geral é um desperdício. E muitas vezes um erro. Use argumentos nas funções, e retorne algo delas. É mais esperto e expressivo. Não há razão para incluir conio.h. Essa é uma biblioteca dos anos 80 e nada acrescenta a um programa moderno. Mesmo nos anos '80 ela era usada em geral apenas para ler letrinhas do teclado sem mostrar na tela, limpar a tela e escrever letrinhas com cores --- getch(), kdhit(), clrscr() e textcolor(). A mesma coisa que estava disponível em C no Windows e no Unix (depois Linux/MacOS/Android) em poucas linhas mas ninguém lia o manual imagino. Se seu programa tem um menu, entenda que o menu() deve mostrar as opções e ler e retornar a opção. Um void menu() é um desperdício. Nunca escreva um programa interativo. Não vai aprender nada. Não vai ganhar nada. Escreva e teste todas as funções. DEPOIS de tudo testado coloque a parte interativa. isso inclui claro o eventual menu. evite ler do teclado a menos que seja o objetivo do problema. Ler de arquivos é muito mais simples, seguro e fácil de reproduzir. Não há razão para ficar parado em frente a tela minutos inventando nomes de campos e coisas assim: o efeito é que vai acabar não testando direito porque é difícil controlar e repetir testes. Um printf() de 6 linhas é muito, mas muito melhor que 6 printf() de 1 linha. E se só vai mostrar o texto puts() é ainda melhor e dezenas de vezes mais rápido que uma série de printf(). Eis uns exemplos de coisas que só vão te atrapalhar: // Função para imprimir um menu de opções: void menu() { //... } Não é mais simples retornar a opção? Não dá pra imaginar, sem o comentário, que tal função represente um menu? printf("\t\tPEDRA PAPEL TESOURA"); printf("\n\t\t\tby Matheus Marcelino"); printf( "\n\t__________________________________________"); printf("\n\n\t[1] - Jogar"); printf("\n\t[2] - Conquistas"); printf("\n\t[ESC] - Sair"); printf( "\n\t__________________________________________"); printf( "\n\n\tPressione a tecla referente a opção " "desejada."); 8 chamadas a printf sem nenhuma variável? Use puts() dezenas de vezes mais rápido. Ou prefira printf("\n\ PEDRA PAPEL TESOURA\n\ by Matheus Marcelino\n\ \n\ __________________________________________\n\ \n\ [1] - Jogar\n\ [2] - Conquistas\n\ [ESC] - Sair)\n\ \n\ __________________________________________\n\ \n\ \n\ Pressione a tecla referente a opção " "desejada."); Muito mais fácil de ler e de alinhar e dezenas de vezes mais rápido... menu(); opcao = lerOpc( opcao); // declarei uma variável para armazenar o // valor retornado da função lerOpc. Não seria muito mais simples usar int opcao = menu(); e retornar a resposta, que é o que se espera de um menu? E o comentário fez mesmo diferença? Sobre isso: srand((unsigned) time(NULL)); // semente da função rand. provavelmente não precisa disso, mas se quer mesmo usar srand() em um programa que está testando é mais produtivo usar uma mesma semente, que é só um número, tipo 20240104, porque assim durante todos os testes terá a mesma série e assim pode rever cada condição de sorteio....

Tem algo bem errado com o que fez. Na verdade fica mais rápido e não mais lento. Expliquei as razões e mostrei uns números e desenhos e roteiros aqui, mas parei de repetir. Eis alguns tópicos que pode ler (são sobre o mesmo tema): Alguns números Outro caso detalhes aqui exemplo resumo Nunca conecte roteadores secundários via porta WAN. Isso cria outras redes IP e segmenta o tráfego. A primeira rede não vê as outras. As outras veêm a primeira apenas porque nela é que está o gateway padrão dos roteadores. Fora isso quase nada funciona mais direito. Incorre em múltiplo NAT e pode perder metade da banda nas redes que não a primeira só por causa disso. Nada vai funcionar direito com dispositivos que não estejam na mesma rede IP. Isso inclui espelhamento de tela de celulares, compartilhamento de arquivos, impressoras wifi, lâmpadas e acessórios smart e outras coisas. Encaminhamento de portas tem que ser repetido em TODAS as redes secundárias. Broadcast de rede não passa pelos roteadores e assim coisas como Wake-on-LAN não vão funcionar. Desconexão temporárias por alguns segundos acontecem quase sempre devido aos intervalos de lease de DHCP. Acesso remoto é um pesadelo.

Talvez seja um tanto precipitado ir para esse tipo de conclusão. Sabe ao menos se os patch cords são produzidos a partir desses mesmos modestos rolos de 1000ft que se compra na rua? Não acha que pode ter uma máquina alimentada por rolos muito mais compridos e com uma rotina de fabricação e testes especificamente preparada para produzir pach cords?

Esse vídeo é meio bobinho. Em geral em redes domésticas e para pequenas empresas não é nada esperto ligar via porta WAN. Há muita perda de banda (até uns 40 % na segunda rede não é nada surpreeendente), segmenta a sua rede local, torna automação um inferno, coisas bobas como espelhar a tela de um celular na TV pra ver um filme pode ser impossível se o celular estiver em uma rede e a TV em outra. Já postei muitos e muitos tópicos explicando isso, com argumentos, numeros, desenhos e roteiros. Em ambientes comerciais onde se precisa de algum isolamento isso (WAN/LAN) pode até se justificar, mas em ambientes assim não são 2 ou 3 roteadores e se imafina um suporte profissional ou quase isso. A causa mais comum de pequenas interrupções de conexão num roteador configurado do modo como está usando (e está errado) é relacionada à renovação do lease do serviço DHCP que atende o segundo roteador,, se usa isso. E o comum é usar isso porque esses pseudo-tutoriais recomendam isso. Se esse for o problema testar é trivial: veja a rede LAN administrada pelo roteador primario e separe lá um endereço para esse C50, fixo, e assim configure a porta WAN dele, Desse modo ele vai ficar permanentemente conectado, e se a conexão para é um problema físico. E aí troca a porta LAN do outro lado, e depois o cabo, E testa e testa e testa e anota tudo. Eu parei de repetir esses tópicos mas tenho uma lista e vou postar aqui a mesma Alguns números Outro caso detalhes aqui exemplo resumo Nunca conecte roteadores secundários via porta WAN. Isso cria outras redes IP e segmenta o tráfego. A primeira rede não vê as outras. As outras veêm a primeira apenas porque nela é que está o gateway padrão dos roteadores. Fora isso quase nada funciona mais direito. Incorre em múltiplo NAT e pode perder metade da banda nas redes que não a primeira só por causa disso. Nada vai funcionar direito com dispositivos que não estejam na mesma rede IP. Isso inclui espelhamento de tela de celulares, compartilhamento de arquivos, impressoras wifi, lâmpadas e acessórios smart e outras coisas. Encaminhamento de portas tem que ser repetido em TODAS as redes secundárias. Broadcast de rede não passa pelos roteadores e assim coisas como Wake-on-LAN não vão funcionar. Desconexão temporárias por alguns segundos acontecem quase sempre devido aos intervalos de lease de DHCP. Acesso remoto é um pesadelo. Nada disso é ideia minha: esses protocolos são padronizados e tem décadas de idade já. um dos primeiros comentários naquele vídeo, logo depois da publicação (veja lá): pois é.

Ligou esse segundo roteador ao outro via porta WAN ou LAN? Qual o modelo?