Netty + ProtoBuffer: quelques messages de communication pour une connexion

J’ai trouvé le fil de l’auteur de Netty dans les groupes de Google et j’ai compris que je devais changer d’architecture ou écrire mon propre décodeur comme je l’ai écrit ci-dessus. Alors, commencez à penser de quelle manière ce sera facile et meilleur.

Si vous souhaitez malgré tout écrire vos propres codecs, vous pouvez envisager de mettre en œuvre l’interface Externalizable pour des objects de données personnalisés.

• Sérialisable nécessite peu d’effort, mais moins performant (tout sérialiser).
• Protobuf est un bon compromis entre effort et performance (nécessite une maintenance .proto)
• Externalisable est un effort important, mais les meilleures performances (codecs minimaux personnalisés)

Si vous savez déjà que votre projet devra évoluer comme une chèvre de montagne, vous devrez peut-être suivre une route difficile. Protobuf n’est pas une solution miracle.

Théoriquement, cela peut être fait en modifiant le pipeline de chaque message entrant en fonction du message entrant. Jetez un coup d’œil à l’exemple de l’ unification des ports à Netty.

La séquence serait:
1) Dans le décodeur de trame ou un autre “DecoderMappingDecoder”, vous vérifiez le type de message du message entrant
2) Modifiez le pipeline de manière dynamic, comme indiqué dans l’exemple.

Mais pourquoi ne pas utiliser différentes connexions et suivre cette séquence:
1) Ajoutez d’autres décodeurs dans le pipeline en fonction du message entrant une seule fois.
2) Ajoutez la même instance de gestionnaire de canal en amont que le dernier gestionnaire du pipeline. Ainsi, tous les messages sont routés vers la même instance, ce qui revient presque à avoir une seule connexion.

le problème est qu’il n’ya aucun moyen de distinguer deux messages protobuf différents au format binary. Mais il existe un moyen de le résoudre dans le fichier protobuf:

 message AnyMessage { message DataMessage { [...] } optional DataMessage dataMessage = 1; message TestMessage { [...] } optional TestMessage testMessage = 2; message SrcMessage { [...] } optional SrcMessage srcMessage = 3; } 

Les champs facultatifs non définis ne génèrent pas de surcharge. De plus, vous pouvez append un Enum, mais ce n’est qu’un bonus.

Le problème n’est pas tout à fait une limitation Netty ou une limitation codeur / décodeur. Le problème est que les tampons de protocole Google offrent simplement un moyen de sérialiser / désérialiser des objects, mais ne fournissent pas de protocole. Ils ont une sorte d’implémentation RPC dans le cadre de la dissortingbution standard, mais si vous essayez d’implémenter leur protocole RPC, vous vous retrouverez avec 3 couches d’indirection. Ce que j’ai fait dans l’un des projets, c’était de définir un message qui est essentiellement une union de messages. Ce message contient un champ Type et un autre le message réel. Vous aurez toujours 2 couches indirection, mais pas 3. Ainsi, l’exemple de Netty fonctionnera pour vous, mais comme il a été mentionné dans un précédent post, vous devez append plus de logique dans le gestionnaire de logique métier.

Vous pouvez utiliser le tunneling de message pour envoyer différents types de messages sous forme de charge utile dans un seul message. J’espère que cela pourra aider

Après de longues recherches et des souffrances … j’ai eu l’idée d’utiliser la composition de messages dans un message enveloppant. Dans ce message, j’utilise oneof pour limiter le nombre d’objects autorisés à un seul. Commander l’exemple:

 message OneMessage { MessageType messageType = 1; oneof messageBody { Event event = 2; Request request = 3; Response response = 4; } ssortingng messageCode = 5; //unique message code int64 timestamp = 6; //server time }