Menu
▾
▴
edonkey-java-devel
|
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 |
|
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
|
Thanks for helping keep SourceForge clean.
X