1

I'm working on a distributed application that uses DDS for messaging. Some parts of the network are separated by a data diode that only allows one-way data flow (i.e. data can go from A => B but not B => A). This is problematic for DDS so we're considering building a proxy Java app either side:

/-----------\ =>=>=>=>=> PROXY #2 /-----------\ ¦ MESSAGE ¦ => PROXY #1 => => DATA => => Receives TCP, => ¦ MESSAGE ¦ ¦ PUBLISHER ¦ Receives message => DIODE=> converts to message ¦ SUBSCRIBER¦ \-----------/ & converts to TCP =>=>=>=>=> and republishes \-----------/

I'm not very familiar with UDP but my current understanding is a fixed packet size (e.g. 512 bytes) would be desirable. So any messages larger than this would need to be split across multiple datagrams and pieced together by PROXY #2 in whatever order they arrive - and the message only sent when all the pieces have been reassembled.

The question here is how to go about restitching the messages? Am a bit wary about wheel reinvention, e.g. inventing a custom protocol or algorithm if it turns out to already exist.

Community
  • 1
  • 1
Steve Chambers
  • 37,270
  • 24
  • 156
  • 208
  • Why not just use TCP, which retransmits missing packets, puts them back together in the correct order etc? – WillShackleford Aug 21 '15 at 12:17
  • Thanks for the suggestion but TCP involves handshaking and receipt acknowledgements, which wouldn't be possible when the data can only flow one way. – Steve Chambers Aug 21 '15 at 12:24
  • It sounds problematic. If you send a large message you have to get all the packets in order to reassemble and with no way to tell the sending side which packet is missing you would have to throw away the whole batch. It sounds like any custom protocol would have to be specific to this diode situation, and make some trade-offs between reliability and performance, perhaps tuned to the percentage of dropped packets and delays over that connection. Maybe there is specific advice from the supplier of the data diode. – WillShackleford Aug 21 '15 at 14:54
  • Thanks @WillShackleford. Think we're going to go the custom protocol route and invent a fixed size header that contains all the necessary info such as message topic name, sequence number etc. (The sequence numbers would enable lost packets to be identified.) – Steve Chambers Aug 27 '15 at 20:11

0 Answers0