From: Robin <ke...@if...> - 2003-05-17 14:04:11
|
Hello, First of All, if you don't mind, I'd like to introduce some shortcuts: CLC: already known command line client or Core EJC: Edonkey Java Controler EGC: Edonkey GTK Controler GUI: generic Java or GTK (or PHP) Controler I find a little time to work on the EJC, ran through the startup code, up to the serious things: the CoreController Class, the one that handle the communication between the GUI and the CLC. It seems that you are right, the communication and packet handling is somehow...bad. It's as you describe: CoreController: 413 CoreController->ReadThread int header = _in.readByte(); if (isInterrupted()) break; if (header == Packet.HEADER_CHAR) { int size = _in.readIntR(); if (isInterrupted()) break; if (size >= 1) dispatchMessage(_in.readByte(), size - 1, _in); _in is a MetaInputStream. Before being affirmative, I should run deeper in this class, as it's a customized class written for the EJC, maybe the packet is handling correctly, because, the remaining looks like this: CoreController: 591 CoreController->dispatchMessage public void dispatchMessage(byte msgID, int size, MetaInputStream in) { boolean processed = false; try { int start = in.getCount(); switch (msgID) { case Packet.CORE_SERVER_LIST: guiServersList(in.readMetaList()); processed = true; break; Finally, when I look at the MetaInputStream readIntR method, I get this: MetaInputStream: 289 MetaInputStream->readIntR public final int readIntR() throws IOException { int ch1 = read(); int ch2 = read(); int ch3 = read(); int ch4 = read(); if ((ch1 | ch2 | ch3 | ch4) < 0) throw new EOFException(); return ((ch4 << 24) + (ch3 << 16) + (ch2 << 8) + (ch1 << 0)) & 0xFFFFFFFF; } As you can see, the message is parsed in several times: First the Header, than the size (in 4 consecutive read), and then the message id, and after, the contents in several times. It seems clear that your advice and method is better, but I don't know Java enough (I'll look at this in detail later) to know if a single read on the socket would deliver a packet in "one shot" (I'm more experienced with C), I should investigate this. But whatever the method is, reading the header, than the size, than the payload should work in both case (reading a block, or reading byte after byte). I suspect a bug either in the CLC, either in the GUI (I suspect the GUI). I'd prefer to just correct a bug, or adjust a function that read a certain type of message than to rewrite the whole packet reading code (this could come in a second time). Here is where I am. I'm hungry and tired, i'll continue tomorrow or tonight. Thanks for the hint, it seems to be a good point to look at. See you, Robin PS: look at what I find after activating the trace code: Size is not match with actual read: MessageID: 199 size: 123 actual read: 108 ?(-76) Retrieving http://sda.edonkey2000.com/ver/ver.php?ui=2&ver=1.2.0&core=1 0481 (0)(0)(0)(28)(4)(3)(0) the parenthesis correspond to this code: MessageUtils.trace(new String("" + (char) header + "(" + header + ")")); We found a bug, I'll try to find it with more precision, and i'll let you know > 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. Huh, as I said, whatever it receives, if the CLC respects his own protocol (HEADER-SIZE-MSGID-PAYLOAD), there should be no "out of sync" situation. May I suspect the CLC not to respect this simple protocol ? the message: Size is not match with actual read: MessageID: 199 size: 123 actual read: 108 seems to confirm the fact, isn't it ? > 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 > > > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June > 4-6, 2003, Santa Clara > The only event dedicated to issues related to > Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Edonkey-java-devel mailing list > Edo...@li... > https://lists.sourceforge.net/lists/listinfo/edonk ey-java-devel ____________________________________________________________ _________ Envie de discuter en "live" avec vos amis ? Tilicharger MSN Messenger http://www.ifrance.com/_reloc/m la 1hre messagerie instantanie de France |