From: Tim <t....@ze...> - 2003-05-15 06:17:17
|
Hi. This may not be the most urgent item on the list, but it might help to identify problems the JavaGUI has with the core. Maybe it's not an issue at all anyway. The core and the GUI exchange messages in 'packets'. Each GUI-core protocol message is sent in its own packet with a header and further data if required. The packets look like this: Packet header (5 bytes): 1 bytes: 0xe0 = 224 = header byte 4 bytes: packet data to follow (unsigned integer, little endian order) Packet data (N bytes): 1 byte: message from the gui-core protocol. Rest (N-1 bytes): extra data that goes with the message if needed. What needs to be checked is whether the JavaGUI reads the data directly from the network stream (=bad), or whether it first reads in the whole packet and then starts parsing it as a separate entity. The reason why it's bad if the GUI read the data directly from the network stream is that if it receives messages with more data than expected (e.g. change of protocol, extra info appended to a message, bug in the core when creating a packet), then it might run into problems if it doesn't get exactly the data that it expects, because it looses sync of the packet stream. So it would probably a good idea to check what the java gui exactly does in this respect. It should either read in whole packets and parse those separately once read in (e.g. from a ramfile/memory stream or something), or there should be some kind of sync-mechanism that scans the incoming network stream for the next packet header in case of hick-ups. Otherwise the gui will not be able to parse any more incoming messages from the core once it got a single one that is somehow not exactly what it expects. I should add though that I have never actually looked at the code, so I just be totally wrong and this isn't a problem at all... cheers -Tim |