Websocketpp binary options

Postado em protocolos Recentemente eu tive que adicionar um servidor WebSocket para um projeto C. Algumas pesquisas mostraram que as opções aqui são demais. Existem algumas opções baseadas em C, e é claro que você pode escolher o módulo Websocket das bibliotecas POCO 1 se desejar uma abordagem C. Uma vez que este projecto particular é escrito em C I muito preferido uma solução puramente C, de preferência stand-alone. Em última análise, eu escolhi o (criativamente nomeado) Websocket biblioteca 2, também conhecido como Websocketpp. Principais argumentos aqui foram mencionados como sendo uma solução orientada a objetos C, sem dependências significativas, bem como a facilidade de implementação graças a ser uma biblioteca de cabeçalho-somente. Websocket é uma biblioteca bastante modular, fazendo uso pesado de modelos para montar várias configurações, pontos finais e similares em um todo coerente. Como a base para o módulo de transporte pode, por exemplo, escolher a partir de iostreams (muito lento) e ASIO. Para o último um pode escolher entre Boost ASIO e ASIO autônomo. Há também a opção de não usar recursos C11 e usar as alternativas Boost em vez disso. Uma vez que este projecto envolveu uma série de objectivos de compilação, nem todos apresentando um compilador capaz de C11, a configuração final envolveu uma dependência Boost utilizando a sua ASIO e a biblioteca do sistema, bem como várias outras dependências apenas de cabeçalho. Depois de iniciar a integração real da biblioteca em meu projeto, eu no entanto descobrir que a qualidade da documentação é very8230 sub-optimal. A documentação é dividida entre o site do GitHub e o próprio site do autor, com a maior parte desta documentação completamente e completamente desatualizada. Só depois de quantidades significativas de tentativa e erro consegui obter uma implementação totalmente funcional. Para salvar os outros o problema, gostaria de apresentar uma versão (simplificada e alterada) da minha implementação. Espero que seja útil. Let8217s passar para o arquivo de cabeçalho de nossa implementação: Com esses dois inclui nós escolhemos a função de servidor Websocket e disponibilizar a configuração ASIO sem recurso TLS, ou seja, sem conexões criptografadas. Nossa definição de classe implementa uma classe estática. Isso nos permitirá usar a funcionalidade do Websocket de várias classes. Websocket é thread-safe, então tudo o que temos de se preocupar é o acesso de nível multi-thread para nossas próprias estruturas de dados e variáveis. Passando para a implementação, podemos ver primeiro as inicializações estáticas habituais e fusão de namespace: Next é inicializar a biblioteca ea instância do servidor: Ao usar a opção de transporte ASIO, chamamos seu método de inicialização aqui. Podemos querer redirecionar a saída de registro para nosso próprio método de log. O logger básico do Websocket8217s nos permite definir uma alternativa ostream para o padrão std :: cout e std :: cerr. Vamos olhar para isso em mais detalhes mais tarde. Em seguida, definimos os manipuladores de mensagens. Estes são todos os métodos de retorno de chamada que vamos definir em um momento. Com toda a configuração feita, podemos começar a ouvir usando a estrutura de transporte, isso é feito com a chamada listen () no objeto de servidor. Este método não é exceção-livre, assim que nós o cercamos com um bloco do try / catch. Finalmente, começamos a aceitar conexões. Só precisamos iniciar o servidor propriamente dito agora, o que é feito na seguinte função: Novamente, este é outro método que isn8217t exceção-livre, então temos que cercá-lo com um bloco try / catch. A outra pista é que quando desligamos o servidor em algum ponto, temos que esperar por esta (runking) run () chamada para retornar antes de, por exemplo, terminar um thread. Desligando o servidor Websocket é bastante óbvio: primeiro paramos de ouvir. Isso significa que não aceitaremos novas conexões. Em seguida, passamos por todas as conexões websocket que ainda temos e fechar cada um deles. Finalmente chamamos stop () no objeto servidor. Isto não é estritamente necessário, mas irá assegurar que o backend de transporte está completamente desligado e quaisquer ligações restantes terminadas com força. Vamos passar a aceitar novas conexões. Para isso, podemos usar um número de manipuladores 3, incluindo open () e validar. Eu escolhi o manipulador de validação, uma vez que permite filtrar as conexões de entrada e rejeitar qualquer que não autenticar corretamente ou tais: Este código mostra como obter a conexão por trás de um identificador de conexão do Websocket e extrair o URI incluindo sua seqüência de parâmetro de consulta de isto. Aqui nós assumimos que o cliente de conexão tem que fornecer uma ID baseada em strings, embora também se possa usar outro identificador, com base na implementação. Usamos o bloqueio pthread baseado em torno do mapa websockets para garantir que nenhum acesso simultâneo ocorre nesta estrutura de dados e inserir o novo identificador websocket com seu id como chave. Podemos também querer implementar os manipuladores fail () e close (): Para o manipulador de falha, podemos obter a conexão como antes, e extrair o objeto de código de erro para aprender o motivo por trás da falha. O manipulador próximo geralmente deve ser bastante chato, mas pode ser informativo para ter a confirmação em um log ou tal de uma conexão fechada com êxito. Seguindo em frente, temos apenas de olhar para como enviar dados para um tal soquete. Essa função obtém o identificador de conexão apropriado com base no ID e, em seguida, procede a gravar os dados fornecidos para essa conexão. O método getWebsocket () é um esforço trivial de localização e iteração baseado em mapa STL e isn8217t mais documentado aqui. Não se esqueça de bloquear o mapa ao executar as ações find e iterator nele. Por fim, como fechar um soquete: Aqui nós novamente obter o identificador de conexão correta, somente desta vez usamos o método 8216close8217 em vez de 8216send8217. Podemos enviar um motivo próximo usando uma string, ou simplesmente enviar uma string vazia. Finalmente, o ID é apagado do mapa de websockets eo identificador de conexão agora inválido com ele. Com isso, temos tudo o que precisamos para o servidor Websocket, exceto por uma coisa: o redirecionamento da saída de log de Websocket. Vimos anteriormente que usamos o método setostream () nas interfaces de log. Na declaração de classe vimos este misterioso tipo 8216LogStream8217 e um ostream, e novamente nas inicializações estáticas. O que acontece aqui é que esta classe LogStream é uma implementação personalizada do std :: streambuf, atribuído a um objeto std :: ostream que, em seguida, substitui o log padrão Websocket8217s saídas. Para a implementação real streambuf, um iria usar algo parecido com isto: Nós apenas substituir o método virtual overflow () na classe streambuf. Na implementação padrão, o buffer padrão transborda para cada caractere gravado na classe streambuf e, portanto, nosso método overflow é chamado para cada caractere. Usando uma string como buffer, capturamos cada caractere recebido e verificamos se é um caractere de nova linha ou não. Se é que temos uma linha completa que podemos então escrever para qualquer funcionalidade de log que usamos em nosso projeto. Depois disso, esvaziamos a seqüência de buffer e continuamos com a nova linha. Em conclusão, devo dizer que, apesar do esforço que me custou para obter uma integração de trabalho Websocket no meu projeto, eu acho que valeu a pena. Tecnicamente é uma biblioteca bem projetada com um monte de recursos interessantes e graças à sua natureza baseada em modelo de facilidade de expansão e configuração para atender a diferentes finalidades. Sua principal fraqueza é simplesmente a documentação desatualizada, falta e ocasionalmente errado e exemplos. Esperemos que este artigo irá corrigir pelo menos parte desse problema Java em muitos aspectos é uma linguagem de programação muito excêntrica. Ler as respostas do designer8217s a perguntas sobre seu design leva a idéias interessantes, como que tipos de inteiros não assinados seriam confusos e propensos a erros para o programador médio. Há também o pensamento de que Java é puramente orientada a objetos, mesmo que tenha muitos tipos primitivos e conceitos espreitando em suas profundezas. Seu design apresenta problemas muito desconfortáveis ​​para os desenvolvedores que procuram ler, escrever e geralmente lidar com dados binários e arquivos, como toda a linguagem parece ser orientada para formatos baseados em texto, como XML. Isso leva a problemas como como implementar um protocolo de rede binário básico. Muitos protocolos de rede e comunicação são binários, pois isso os torna mais fáceis e rápidos de analisar, mais leves e menos propensos à interpretação. A questão aqui é como implementar tal protocolo em uma linguagem que é totalmente estranho com os conceitos de inteiros não assinados, sobrecarga do operador e similares. A resposta mais elegante que eu encontrei até agora é ficar de baixo nível, e eu realmente quero dizer baixo nível. Vamos tratar os inteiros inteiros incorporados do Java8217s como se eles não fossem assinados usando operadores bit a bit onde necessário e usar byte-arrays para traduzir entre Java e o mundo externo. O tipo de byte em Java é um inteiro assinado de 8 bits com um intervalo de -128 a 127. Para nossos propósitos, iremos ignorar o bit de sinal e tratá-lo como um inteiro não assinado de 8 bits. A comunicação de rede ocorre em fluxos de bytes, com o lado receptor interpretando-o de acordo com um protocolo predefinido. Isso significa que para escrever no lado Java para o soquete de rede, teremos que colocar os bytes necessários em uma matriz de bytes preparados. Como as matrizes de Java são de tamanho fixo, como em C, faz mais sentido utilizar uma matriz de bytes por campo ou pré-alocar toda a matriz e copiar os bytes para ela. A escrita é feita no Java Socket via seu OutputStream que nós embrulhamos em um BufferedOutputStream. Quaisquer cadeias ASCII no protocolo que definimos como bytes individuais. Felizmente os códigos ASCII só vão para 127 (0x7F) e, portanto, cabem dentro da parte positiva do tipo de byte Java8217s. Para valores que se estendem para o intervalo negativo do byte, poderemos ter que usar o bit masking para lidar com o bit de sinal, ou fazer a conversão nós mesmos. Definimos a versão do protocolo como um int (BE assinado, 32 bits), que convertemos para um byte usando um elenco simples, removendo os três bytes mais altos. Novamente preste atenção ao valor do int. Se it8217s maior que 127 você tem que lidar com o bit de sinal novamente ou arriscar um estouro. Neste exemplo, implementamos um protocolo de menor-endian (LE). Isso significa que na conversão para uma matriz de bytes de um inteiro de 16 bits ou maior, temos que colocar o LSB primeiro, como é feito na função intToByteArray (). Também adicionamos um indicador de comprimento de mensagem no início da mensagem we8217re enviando na forma de um int, estendendo a mensagem por 4 bytes. Ler a resposta e interpretá-la é similar: trata-se de uma amostra breve e ingênua que apenas tem de ler uma única resposta, ignorar o indicador de comprimento da mensagem e ler apenas cinco bytes. Em uma aplicação mais complexa você converteria as seções individuais da matriz de bytes para seus respectivos formatos (strings, ints, etc.) e as verificaria. Para isso, você usaria uma função para inverter a partir da matriz de bytes de ordem LE para o int de ordem BE, como a seguinte: De muitas maneiras é irônico que o bit muda e os operadores bit a bit são o caminho a percorrer com uma linguagem que se perfila como uma alta , Mas tal é o resultado das escolhas de design feitas. Embora seja verdade que o código de matriz de bytes acima orientado poderia ser encapsulado por classes de fantasia que levaria o tediousness fora de implementar tal protocolo, em essência, eles fariam exatamente o mesmo como detalhado acima. Com a próxima versão do Java 8, os inteiros não assinados serão introduzidos pela primeira vez de forma limitada, mas para a maioria dos projetos (incluindo os baseados no Android) it8217s não é uma opção para atualizar para ele. Para referência, o código acima é usado em um projeto real I8217m trabalhando e é, tanto quanto eu sei funcional. No entanto, não posso aceitar qualquer responsabilidade por qualquer coisa que vai mal, aplicativos quebrando, casamentos rasgados ou animais de estimação incendiados. Quaisquer outras verificações e manipulação de erros é provavelmente uma idéia incrível para tornar o código mais robusto. Entre os termos de som mais assustadores e oficiais na computação encontramos a palavra 8216protocol8217. Seu significado realmente não é assustador, no entanto. Assim como quando usado em outros contextos, tudo o que significa é uma coleção de acordos sobre como ir sobre algo. Neste caso, estamos falando de protocolos de comunicação, protocolos que permitem que dois ou mais dispositivos e / ou aplicativos se comuniquem uns com os outros. Muito parecido com como os humanos desenvolveram seus próprios protocolos de comunicação, basicamente. Nós também fazemos uma parte de handshake durante a qual nós inicializamos a conexão, seja ela sorrindo um para o outro, observando o clima bonito / terrível ou perguntando depois de algo específico, dependendo se houve contato anterior ou não. Possíveis modos de falha incluem ficar ignorado (Server Time-out), recebendo slapped no rosto após uma falha pick-up linha (Connection Closed By Host) ou interrompido pelo girl8217s muscular namorado (Connection Reset By Peer), bem como abordar a Pessoa errada (Conexão Negada). Após estabelecer com êxito a conexão, as informações são trocadas. Para os seres humanos, tanto durante o aperto de mão como na comunicação, a forma usada para o intercâmbio de informações é uma chamada linguagem, um conjunto de sílabas um tanto orgânico e informal que, quando colocadas na ordem certa (8216spelling8217 e 8216grammar8217), podem ser usadas para evocar a compreensão na parte receptora . Para chegar até esse nível, os seres humanos precisaram de dezenas de milhares de anos para evoluir uma série de grunhidos e outros ruídos aleatórios em algo coerente. Basta dizer que os protocolos de comunicação humana são elaborados, imprecisos, cheios de mal-entendidos e são um claro exemplo de como não projetar um protocolo de comunicação Finalmente, terminando a conexão. Mais uma vez, para os seres humanos isso pode assumir muitas formas, geralmente não resulta em uma terminação limpa e pode adicionar muitos mais minutos a uma conexão. Aren8217t estamos felizes agora que estamos projetando um protocolo de comunicação para computadores Todos brincando de lado, projetar um protocolo de comunicação é bastante fácil. A primeira escolha que temos de fazer é se queremos que o protocolo seja binário ou baseado em texto. Protocolos baseados em texto incluem o protocolo HTTP, que é o que usamos para navegar páginas da web com. O principal benefício dele é que é fácil para os seres humanos escrevê-lo e depurá-lo. A principal desvantagem é que ele é menos preciso e exato que geralmente você pode analisá-lo de uma só vez, pode verificar instantaneamente que ele é válido como um todo e usar a codificação de texto errada pode estragar as coisas muito mal. Você descobrirá rapidamente que é uma maneira incómoda e propensa a erros sobre um protocolo de comunicação. Não é de admirar que eles sejam bastante raramente usados, principalmente com aplicativos de rede por algum motivo. Os protocolos baseados em texto têm o benefício de não serem afetados pela endianness 1, que é a ordem de bytes usada por um sistema particular. Little endian é o que processadores Intel e AMD usam e significam que os bits menos importantes (pouco) são colocados na frente de um byte, enquanto endian grande é o oposto. Isto significa que se tomarmos o número 14 (hexadecimal 0x0E), em little endian um inteiro resultante de quatro bytes se parece com isto: 0E 00 00 00, enquanto que com big endian parece: 00 00 00 0E. Confundir little endian com grande ou o contrário pode levar a interpretar o número erradamente e fazer o nosso pequeno número de 14 em um número muito maior de 917.504. Ups. Para resolver este problema com protocolos binários que podem ser usados ​​em ambientes mistos endian, adicionamos um número mágico à frente do cabeçalho, geralmente dois bytes com valores conhecidos. Ao ler aqueles que sabemos que endianness os dados está dentro Um exemplo é usando 8216MM8217 como em cabeçalhos de arquivo TIFF para indicar big endian (MSB) e 8216ll8217 para indicar little endian (LSB) ordem de bytes. Podemos então inserir uma rotina de análise diferente, ou trocar a ordem de bytes durante a análise. Escrever o protocolo em si é uma tarefa bastante fácil e na minha experiência divertida, mas eu posso apenas ser um pouco louco. É mais fácil quando você sabe quais são os requisitos para o protocolo, mas, em geral, começamos com o indicador endianness se necessário, em seguida, um ou mais indicadores identificando o cabeçalho como sendo o que é esperado. Eu geralmente uso o nome da minha empresa seguido pelo nome do protocolo. Depois disso os dados se seguem. Seções dentro dos dados têm seus próprios cabeçalhos de texto para detectar a corrupção. Quando os deslocamentos aren8217t são corrigidos, como com strings de texto, um inteiro sem sinal precede os dados para indicar o comprimento do segmento. O protocolo básico, portanto, parece o seguinte: Para enviar um protocolo UDS 8216LIST8217 comando para o servidor, usaríamos o seguinte código, este usando um QByteArray: Eu mencionei ainda que os operadores bit a bit são importantes Quando se lida com interações de baixo nível, como Protocolos de comunicação, eles são inestimáveis ​​e one8217d fazer bem para estudá-los. Finalmente, I8217d gostaria de comentar sobre a 8216size8217 variável usada. Com protocolos de rede é difícil para o soquete de recepção saber quando o fim dos dados foi atingido. Colocar o tamanho de todos os dados na frente do cabeçalho como este permite que ele saiba exatamente quanto de dados ainda tem que ser recebido, quando o final dos dados foi atingido e quando um download está incompleto. Analisar o protocolo é essencialmente o oposto de colocá-lo em conjunto. It8217s feito de forma linear, com cheques para cada valor lido. Se feito direito it8217s muito robusto e bastante tolo-prova. Enfim, estes são os conceitos básicos de colocar um protocolo de comunicação em conjunto. It8217s muito fácil, absolutamente não assustador e até mesmo muito divertido Vá dar-lhe uma tentativa algum time. Server iniciado mensagens Uma das principais razões para usar um WebSocket sobre outros tipos de solicitações HTTP é permitir que o seu servidor para empurrar conteúdo para o cliente no momento Quando o cliente não pediu explicitamente algo. Responder a uma mensagem do WebSocket usando o WebSocket é direto, como demonstrado pelo exemplo do echoserver. Se, no entanto, você quiser enviar mensagens com base em eventos no lado do servidor, você precisará de um pouco mais de código. Examinaremos dois exemplos. O primeiro é um servidor de difusão, o segundo um servidor de telemetria. Broadcast Server É semelhante ao servidor de eco em que as mensagens de entrada são ecoadas de volta, mas diferentes em que eles são ecoados de volta para todos os clientes conectados ao invés de apenas o remetente. Para enviar uma mensagem, precisamos de um token que identifique a conexão. Esse token no WebSocket é o connectionhdl. No exemplo do echoserver, o connectionhdl foi fornecido pelo callback onmessage. Todos os callbacks do manipulador incluem um connectionhdl que identifica a conexão que iniciou o manipulador. Para um servidor de broadcast, onmessage precisará chamar send para cada conexão, em vez de apenas o remetente. Para conseguir isso, precisamos manter uma lista de todas as conexões pendentes. Isso pode ser feito armazenando uma lista de connectionhdls preenchidos pelo manipulador onopen e podados pelo onclose. Para cada mensagem recebida, essa mensagem é então copiada em um loop para cada connectionhdl na lista. Nota: Este é um programa básico e simplificado. Erro verificar caminhos de código foram removidos para demonstrar mais claramente a lógica de núcleo. Nem todos esses programas precisarão verificar todos os erros. Você deve verificar e lidar com os que são apropriados para o seu aplicativo. Em segundo lugar, este servidor de difusão simplificado não será bem dimensionado. Os manipuladores do WebSocket bloqueiam funções de rede do núcleo. Enquanto este programa está executando seu loop de envio em onmessage, nenhuma nova conexão está sendo processada e nenhuma nova mensagem está sendo recebida. Isso funcionará bem com um pequeno número de conexões, mas vai quebrar mal quando ampliado. Em geral, para manter a capacidade de resposta em altas taxas de mensagem ou altos níveis de simultaneidade, os manipuladores devem passar solicitações de processamento para outros segmentos de trabalho para realmente executar o trabalho. O exemplo de servidor de difusão incluído na origem da biblioteca corrige ambos os problemas. Se você estiver interessado em ver um exemplo de desempenho superior com verificação de erros, consulte esse código. Servidor de telemetria de origem do programa Enquanto o servidor de difusão empurra mensagens para conexões não solicitadas quando os dados estiverem prontos, tudo começa com uma mensagem de uma conexão. Se você quiser empurrar dados com base em um evento realmente iniciado pelo servidor e não uma resposta a qualquer entrada de entrada há algumas opções. Counterver: Thread ou loop de evento externo Este método usa um thread separado (um loop de evento externo em outro thread funcionará também). O servidor de contagem usa outro segmento para dormir por um tempo e, em seguida, incrementar um contador e envia o novo valor para todos os clientes conectados. Nota: Como o servidor de broadcast acima, este é um programa simplificado. Inclui o núcleo do programa para a claridade mas omite o código detalhado da verificação de erro. Transport :: asio ontimer TODO: notas sobre este onewebsocketpp Alterações destacadas Alterações menores de quebra Um novo método necessário foi adicionado à api de política de transporte e soquete. Uma implementação é opcional. Todas as políticas de transporte incorporadas foram atualizadas. Os autores de transportes personalizados precisarão, no mínimo, adicionar um método vazio com a assinatura correta. Uma limpeza de dependência relacionada C11 trocou a dependência de libboost-datetime para libboost-chrono para compiladores C03 usando Boost versão 1.49 e posterior. Os compiladores C11 não precisarão mais de libboost-datetime. C03 compiladores usando Boost 1.48 e versões anteriores não são afetados e ainda exigirá libboost-datetime. Adiciona manipuladores de HTTP não bloqueadores Os manipuladores de http não bloqueadores fornecem melhorias significativas de desempenho para aplicativos que precisam servir uma resposta HTTP de execução mais longa sem bloquear o tráfego do WebSocket. Consulte a página do manual do manipulador de HTTP para obter informações sobre o uso. Asio Transportes TLS / Security related improvements O Asio Transport agora suporta conexões de saída usando o SNI quando a versão subjacente do openssl o suporta. Os exemplos agrupados que utilizam a configuração Asio configurada para TLS agora demonstram como obter a conformidade com as configurações TLS recomendadas pela Mozillas. Echoservertls compilado com a bandeira moderna e uma versão moderna do openssl passa agora o teste de servidor SSL Labs com um grau de A. Standalone Asio agora suportado Asio Transport pode opcionalmente usar autônomo Asio em vez de Boost Asio. Isso permite o uso do transporte Asio com um ambiente de compilação C11 sem bibliotecas Boost. Para ativar, defina ASIOSTANDALONE antes de qualquer cabeçalho WebSocket ou Asio. Processador de escrita vetorial de transporte Raw / iostream O transporte raw / iostream agora pode opcionalmente registrar um manipulador para gravações vectorizadas ou de dispersão / colheita. Isso resulta em menos callbacks e permite um empacotamento mais eficiente de várias pequenas gravações em um único pacote TCP ou registro TLS. Se nenhum manipulador de escrita vectored for definido, o manipulador de gravação padrão será chamado várias vezes. Esta versão inclui uma série de correções de bugs e limpeza de código / api. Há um pequeno punhado de pequenas API quebrando mudanças de 0.3.0. Mesmo assim, atualizar de 0.3.0 para 0.4.0 deve ser direto para todos os usuários e é altamente encorajado. Alteração de tipo de exceção de alterações A alteração de quebra primária é a alteração no tipo de exceções que lança WebSocket. Antes da versão 0.4.0 exceções foram lançadas com um tipo personalizado websocketpp :: lib :: errorcode. Isso apresentou uma série de questões, principalmente relacionadas a não derivar da norma std :: excepção base e não corresponder a semântica de std :: exception. Começando na versão 0.4.0 todas as exceções lançadas pelo WebSocket serão do tipo websocketpp :: exception que deriva de std :: exception. Isso normaliza todos os tipos de exceção sob a hierarquia de exceção padrão e permite que exceções do WebSocket sejam capturadas na mesma instrução que outras. O código de erro que foi lançado anteriormente é envolvido no objeto de exceção e pode ser acessado por meio do método websocketpp :: exception :: code (). Mudança de Política de Registo Personalizada A API para criação de políticas de registo personalizadas foi actualizada para ser ligeiramente mais genérica. Em particular, já não exige o uso de std :: ostream. Como resultado, quaisquer políticas de registro personalizadas precisarão alterar / adicionar alguns construtores para corresponder à nova API. Todas as políticas de log fornecidas com o WebSocket (a política stub / none eo logger ostream padrão) foram atualizadas. Se você usar somente as diretivas de log padrão, não há alterações que você precise fazer. Assinaturas de métodos de utilidade Três métodos de utilitário tiveram suas assinaturas atualizadas. Esses métodos não fazem parte da API pública do WebSockets, mas alguns usuários podem usar as versões incluídas em vez de incluir suas próprias bibliotecas por conveniência. Se você estiver usando qualquer um desses métodos de utilitário, talvez seja necessário atualizar os sites de chamadas: Duas versões alpha 0.3.x foram feitas desde a última atualização. Nenhum recurso importante foi adicionado. Alguns pequenos recursos foram adicionados e muitos bugs foram corrigidos. Os destaques destes são incluídos abaixo, as notas de versão completas podem ser encontradas no próprio repositório, bem como na página Alterar Log. Alterações destacadas Remove a dependência da biblioteca boost / std ltregexgt. Isso traz compatibilidade completa do C11 com o GCC 4.6 e evita o requisito de empacotar o binário regex bastante grande para aplicações embutidas com espaço limitado. O cabeçalho HTTP que processa a sensibilidade a maiúsculas e minúsculas foi retrabalhado. Caso usado para cabeçalhos de leitura é ignorado por especificação HTTP 1.1. Caso para cabeçalhos você definir será preservado para ajudar a lidar com outras implementações HTTP que exigem certos casos. As licenças de biblioteca de terceiros incorporadas foram consolidadas no arquivo COPYING. A biblioteca de Sha1 foi substituída por uma diferente sob uma licença de BSD melhor que uma licença do freeware para endereçar preocupações sobre a formulação ambígua da licença. Todas as bibliotecas empacotadas agora usam o Expat MIT ou o licenciamento BSD. O transporte Asio introduz o método stoplisten para permitir que um servidor pare de aceitar novas conexões. Iostream transporte introduz setsecure. Setremoteendpoint. Eof. E fatalerror métodos para permitir que os usuários deste transporte para passar informações sobre a conexão através da biblioteca. Atualizações fecham tipos de código e validação com base em atualizações recentes para o registro IANA. Atualiza a segurança do segmento de transporte asio e re-introduz fios para permitir que pools de threads ioservice para trabalhar novamente. Remove o código experimental não utilizado. Isso deve reduzir o uso de memória e melhorar o desempenho, especialmente de criar e destruir conexões. Roadmap for 0.4.x A versão alpha4 hoje provavelmente será a última alfa 0.3.x. A próxima versão será marcada 0.4.x como haverá algumas (muito menor) rompendo api alterações. O ramo 0.3.x agora está completo. Ele foi publicado e marcado como 0.3.x-alpha2 no ramo principal no GitHub. Isso inclui o código que costumava ser o experimental e 0.3.x-cmake ramos. Esses ramos estão agora obsoletos e serão excluídos em um futuro próximo. Todos os lançamentos a partir deste ponto serão encaminhados para o ramo master e semanticamente versionados. Os logs de alterações detalhados estão disponíveis na página de registro de alterações, bem como no changelog. md no repositório. A documentação do Doxygen para a filial 0.3.x está agora disponível em doxygen. websocketpp. org Os relatórios de Autobahn para a filial 0.3.x estão agora disponíveis em autobahn. websocketpp. org WebSocket agora suporta proxies explícitos para conexões de cliente de saída (ws e wss) Alterações básicas cmake compilação amp install suporte adicionado timers de nível de transporte foram implementadas (proxy / connect / DNS resolver / soquete desligamento / handshake TLS) temporizadores nível WebSocket foram implementadas (open / close handshake, ping / pong timeout) Adicionado métodos de conexão para recuperar Os códigos de fechamento, as razões eo código de erro subjacente das conexões fechadas Suporte de proxy de saída explícito Corrige um número de problemas com o comportamento de fim de conexão, especialmente para clientes. TLS desligamento não está mais bloqueando Hybi00 close frame apoio Lotes de documentação remove arquivos não utilizados e outros códigos mortos Roadmap para a versão final 0.3.x continuar a limpeza estilo de código bugfixes mais documentação mais testes Roteiro para 0.4.x 0.4.x será para trás Compatível com 0.3.x Implemente a extensão permessage-deflate Remove a dependência no cabeçalho ltregexgt que tem suporte insuficiente no GCC Novos recursos para o ramo 0.3.x (experimental) em abril: Subprotocol Negociação Hixie 76 / Hybi 00 suporte Outgoing proxy proxy explícito para WS e WSS conexões Autenticação de proxy: Esquema de autenticação básica Capacidade de registrar em um fluxo arbitrário (incluindo arquivos) Melhoria de detalhes, consistência e desempenho de log de erro e acesso Diversos novos exemplos (cliente de telemetria, servidor de impressão, testeeserver, iostreamserver) Ajustes para melhorar o suporte para Visual Studio biblioteca cria e passa testes em arquiteturas 32 bits e PowerPC. Roadmap for May: O último recurso de bloqueio para a versão 0.3.0 é a implementação de tempos limite para vários eventos relacionados à rede. A maioria dos outros trabalhos estarão relacionados ao teste e correção de bugs em preparação para uma versão oficial do beta 0.3.0 ao final do mês. Aviso para usuários da versão 0.2.x. Se o seu software ou sistema de compilação estiver contando com a versão 0.2.x sendo o ramo principal no GitHub, você precisará fazer algumas mudanças no futuro próximo. Gostaria de incentivá-lo a atualizar seu código para as interfaces 0.3.x. Se isso não for possível, existe agora uma ramificação 0.2.x no Git que irá manter 0.2.x código indefinidamente. Novo Fórum / Listas de discussão Este é um fórum aberto de discussão / suporte para perguntas de uso, solicitações de suporte, solicitações de recursos e outras discussões relacionadas ao desenvolvimento mais detalhadas que não são apropriadas para um problema do GitHub. Em geral, se o tópico de resposta / discussão for útil para outras pessoas depois que o problema for resolvido, ele deve ser incluído nesta lista em vez de um problema do GitHub. Esta é uma lista de discussão moderada de baixo volume que incluirá essas atualizações mensais de desenvolvimento, bem como notificações de novas liberações oficiais da biblioteca. A partir desta noite, a filial do WebSocket 0.3.x (experimental) foi atualizada com uma série de novos recursos que o aproximam muito da paridade com 0.2.x. A última grande característica ausente, a função do cliente, foi concluída. 0.3.x agora tem uma função de cliente disponível, incluindo ltwebsocketpp / client. hppgt e três novas configurações padrão, coreclient, asioclient e asionotlsclient. Eles refletem as respectivas configs do servidor. A função do cliente funcionará sem rede através do transporte iostream ou via TCP / IP utilizando o transporte Boost ASIO. O cliente 0.3.x passa todos os testes de conjunto de testes de autobahn estritamente. Um exemplo de cliente está disponível na pasta de exemplos. Outras alterações notáveis ​​recentes: Todos os exemplos e testes de unidade compilados e executados em processadores Intel de 32 bits (i686) Suporte a RNG Classe de base de ligação substituível Novos exemplos e páginas de manual Os readmes para os dois ramos principais foram atualizados com informações mais detalhadas sobre o Status de cada filial. Estes continuarão a ser actualizados. Remaining features before 0.3.x will be ready to replace version 0.2.x: Subprotocol Negotiation Hybi00/Hixie76 protocol support PowerPC/ARM bug fixes Performance tuning, particularly in the area of message buffer pools Unless you need these features specifically, 0.3.x is the recommended version. I have long been interested in writing and experimenting with web based virtual worlds. Some of my more recent projects in that area ran into communication limitations. In 2018 there was no good way to do low latency bidirectional communication to a browser without resorting to non-standard plugins. While researching my options I came across the IETF hybi working group that was chartered to develop exactly what I was looking for. As this is a capability I felt the web sorely needed a standard solution for I joined the group. WebSocket was born as an early implimentation of the WebSocket protocol to test out ideas proposed by the working group and later on performance and interoperability tests. In the last two years there have been three major versions of WebSocket. Versions tagged 0.1 were very rough experimental versions and not compatible with the final RFC6455 spec. It can be found in the legacy branch on GitHub. Version 0.2 was built for performance and interoperability testing (alongside my work implimenting tests for the Autobahn suite ). It can be found in the Master branch on GitHub. While it is a complete implimentation of RFC6455 a number of early design decisions made it impractical for certain use cases, especially those involving multithreading. In the year or so that version 0.2 has been available I have gathered a great deal of feedback about how developers are using C WebSocket libraries. Ive continued to work with the hybi group on standardizing some extensions to the WebSocket protocol, in particular message compression. The completion of C11 has also brought a number additional options that make sense to use. To address these issues and build a library more suitable for general purpose usage I have been working on a third (and hopefully final) version of the library, 0.3. If no major issues are raised, 0.3 will become the stable 1.0 release. High performance, standards compliant, open source, C WebSocket client and server library.