Menu
▾
▴
edonkey-java-devel — For Java programmers. Discussions about hacking the JavaGUI source code
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(10) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-22 12:22:51
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: <v7...@gm...> - 2003-09-08 05:32:50
|
The source Code should be available here with CVS: http://sourceforge.net/projects/edonkey/ the first thing to do before implementing new things, would be fixing the data-traffic between GUI and core, for core-versions 0.5x. At the moment the gui can only display the names of the download but all other data exchange between core and gui has changed with the new core versions. There are also some other guys who wanted to take a look at the source code in this forum: http://forums.edonkey2000.com/phpBB/viewforum.php?f=21 http://forums.edonkey2000.com/phpBB/viewtopic.php?t=52701&start=0 Perhaps the developers at the gtk-gui site could help you with stuff that has changed since the old 0.4 versions (they can't code java they say but they will know the data that is transfered between the two apps.) http://ed2k-gtk-gui.sourceforge.net/index.shtml Hopefully i could help you a bit, cause we are waiting so long for a new version of the java-client. so long spectra !! x> Hi, x> How can I help ? x> I am a Java developper with 5 years of xprience. x> Where are the sources ? x> I want to see them for evaluating the work to do. x> Is there a TODO list ? x> -- x> xvolks |
|
From: William R. <wp...@co...> - 2003-09-08 05:28:49
|
I've fixed up the uploads in the controller and since the core isn't exactly all that good at removing upload slots there's a timer on the uploads. If they aren't updated for 100 seconds they are removed. I've also toasted a few of the columns in the GUI so if nothing shows up for you find the .eDonkey/settings.properties file (should be in your home directory) and either delete it or remove the lines that say DownloadColumns=blah and UploadColumns=blah --William |
|
From: xvolks <xv...@or...> - 2003-09-06 13:21:39
|
Hi, How can I help ? I am a Java developper with 5 years of xprience. Where are the sources ? I want to see them for evaluating the work to do. Is there a TODO list ? -- xvolks |
|
From: Tim <ti...@ed...> - 2003-08-14 06:14:58
|
Hey guys, I just want to document some recent GUI-core protocol changes here, so they are easier to find for interested parties: * CORE_DOWNLOAD_GAP_DETAILS: instead of a 16-byte download hash the core now sends a 32-bit (4-byte) 'unique integer ID' that identifies a download. We get that ID at the end of the CORE_NEW_DOWNLOAD message. * CORE_DOWNLOAD_STATUS: instead of a 16-bit 'number of download in download list' the core now sends a 32-bit (4 byte) 'unique integer ID' that identifies a download. We get that ID at the end of the CORE_NEW_DOWNLOAD message. * CORE_NEW_DOWNLOAD: We now additionally get at the end a 32-bit/ 4-byte 'unique integer ID' that identifies this download (used in the DL status and gap details messages). Cheers -Tim |
|
From: Tim <ti...@ed...> - 2003-06-12 18:44:30
|
Hi, Just to let you know I'm back from holiday now. Did anyone find out anything while I was away? :-) cheers -Tim |
|
From: Robin <ke...@if...> - 2003-05-19 21:48:24
|
Hi, That's right, we get this working better. The search result bug is maybe not in the Network code. As far as I can see, packets are well received (read bytes=sent bytes), they are either badly read. Or this could be an old bug: sometimes, in previous versions, when there was too much results, the number of results appear, but not the list of results. This is worst now. The weird thing is that under certain (unknown!) circumstances, I managed (only once!) to get 3 file search results displayed. I think it was in sending the search by hand on the CLC. There may be another strange bug in this routines when a search in running from the EJC, I can't display any results in the CLC with a vr...the mix in searching from the CLC or the EJC seems quite strange. Tim, could it be a core bug ? TODO: try to understand what the hell is going on with search stuff TODO 2: when the EJC connects to a CLC already connected to a server, it appears as not connected to the server, and search is impossible, and you have to reconnect from the EJC for it to know is connected to a server. Either find what is the bug in the "Is the CLC connected to a server when the GUI connects" code (it worked before), and if needed, add a function to check if the CLC is connected at GUI connection (like a 'g' CLC command). Maybe we should find the function that asks to the CLC how many files and clients the server has, and run it at startup (seems simple, just have to understand what we do)! TODO 3: add the stuff to see the "uploading slots" (Tim talks about a new network message format, and I have a type of message always in read error...more information to come) TODO 4: the download speed seems strange, needs to investigate more to see this. It seems that the DL speed is not displayed in the "downloading files" slots. To be continued. I'll try to find some time to work on it this week, between two girlfriends and two movies (matrix 2 makes me cry of laugh or laugh to tears I don't know !). Good Holiday Tim. Robin PS: did you ask for the download edonkey page to be modified pointing to sourceforge ? > Hi, > > just wanted to let all those lurkers on the list > know that we had some limited > success in making the Java controller work with > recent edonkey cores. > > Robin identified a problem the Java controller > had with the NEW_DOWNLOAD > messages (ie. unknown float meta tag type), which > is fixed in CVS now, so > that it should now be possible to connect the > Java controller to a recent > core, and to see the downloads and manage them as well. > > The next thing that needs fixing seems to be the > search. Apparently the Java > controller does not display search results > (neither results from the main > server, nor 'extended' search results). > > Here is what the format of the search messages looks like: > > CORE_NEW_SEARCH_RESULTS (msg 187): > * unsigned integer (4 bytes): number of results (=N) > * N file meta records (see below) > * boolean (1 byte): there are more results available > > CORE_SEARCH_RESULT (msg 186): > * 1 file meta record (see below) > > Each file record looks like this (in eDonkey): > * 16 bytes: file hash > * 4+2 bytes: ignore (ip+port) > * a standard meta tag list follows (the format of which > has not changed), containing further infos about the > file (size, name, metainfo, etc.) > > Each file record looks like this (in Overnet): > * 16 bytes: file hash > * 16 bytes: ignore > * a standard meta tag list follows (the format of which > has not changed), containing further infos about the > file (size, name, metainfo, etc.) > > I'm not sure why the search results stuff doesn't > work in the controller. I > don't believe anything has changed here. Maybe > there are other meta tags that > the MetaInputStream doesn't know how to deal with > - like TYPE_HASH (0x01). > > > Anyway, I am going to be away for three weeks. I > hope you guys manage to > figure out some more stuff, and that when I come > back everything works > flawlessy, hehe ;-) |
|
From: Robin <ke...@if...> - 2003-05-18 11:09:42
|
> > > [snip] > > > > 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 ? > > >No, the CLC respects this protocol. The CLC will > always produce packets > >where a header that says 'size=X' is followed by > X bytes of data. > Always :->) > > If the packets that the core sends out to the GUI > are always correct > according to the 2 bytes for length, then there > shouldn't ever be an out > of sync problem if the EJC is properly coded. Yes there is, in fact, the problem is in the end of the dispatchMessage switch, the patch sent by Tim was good but not enough to solve the problems. At the end of the switch, if the packet is not "processed", it flush the packet, but if the packet is "processed", it displays a message "size mismatch", but doesn't flush, I continue working on it, keeping the first Tim Patch. > I just got back from Cornell, so I've got to > finish unpacking and such, > but since I don't start work for another week > I'll futz around with the > packet handling code next week. I hope it will be fixed at this time, but the more we'll be, the better it will be. See you, Robin |
|
From: William P. R. I. <big...@co...> - 2003-05-18 02:47:20
|
> > [snip] > > 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 ? >No, the CLC respects this protocol. The CLC will always produce packets >where a header that says 'size=X' is followed by X bytes of data. Always :->) If the packets that the core sends out to the GUI are always correct according to the 2 bytes for length, then there shouldn't ever be an out of sync problem if the EJC is properly coded. I just got back from Cornell, so I've got to finish unpacking and such, but since I don't start work for another week I'll futz around with the packet handling code next week. --William |
|
From: Robin <ke...@if...> - 2003-05-17 14:39:08
|
> > CLC: already known command line client or Core > > EJC: Edonkey Java Controler > > EGC: Edonkey GTK Controler > > GUI: generic Java or GTK (or PHP) Controler > > ok, I'm not used to those, but I'll try to adhere > to them as much as possible > ;-) Thanks, you don't have to if you don't want, if you are used to others shortcuts let me know we can use them. But using such abbreviations is always a little annoying in the beginning, but always useful after. > > It seems that you are right, the communication > and packet > > handling is somehow...bad. > > It's as you describe: > > hmm, I think that should be stuff that should be > on the list, if you ask me. > As you replied privately though, I'll reply > privately as well. You can then > decide if you want to forward it or not (in whole > or only parts) ;-) Don't pay attention, it was a mistake, i wanted to write to the list. > I had a quick look at CoreController.java in > jc/src/com/mm/net/, and found > basically only the following issue: > > * how does the EJC behave if the packet size > doesn't match the size read? > > (a) if read > packet size: not sure what > happens. This case should not > happen though. > > (b) if packet size > read: line 745 should > show a message > "size is not match with actual read" > (sic). The problem that I see is > that the EJC might not read in those > 'superfluous' bytes, nor will it > skip those bytes. But maybe I'm just wrong :-) > A simple 3 lines here could resolve quite > a few problems (see below). I have to go deeper in the code of the MediaInputStream to see how it works, I'll answer more precisely after. > > [MetaInputStream stuff:] > > 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). > > Maybe we should leave that stuff alone then for > now, and rather fix the stuff > as it is, that might be easier? Yes, packets in error are: Got MessageID: 199 but size is 123 Got MessageID: 262 but size is 305527903 Got MessageID: 188 but size is 107 Got MessageID: 188 but size is 119 If you have the exact format of this packets, it will save me the time to look at the EGC code. > > 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). > > yes, agreed. Just ignore my first mail to the > list then :-) No problem, incoming packet handling code will be rewritten after. > > 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 > > aaah. The newer cores send an options message as > one of the first messages > when the GUI connects. So if the GUI fails here, > everything else will be > unlikely to work, as the EJG apparently does not > re-sync the input stream to > the next packet header. > > Try inserting this code in CoreController.java > from line 735 and see if that > makes it work: > > if (!processed) { > byte[] result = new byte[size]; > int read = 0; > while (read < size) > read += in.read(result, read, > size - read); > MessageUtils.trace(new > String(result) + "\n"); > } > else { > int end = in.getCount(); > + byte[] resttoignore = new byte[end-read+1]; > + while (read < size) > + read += in.read(resttoignore, > read, size - read); > if (end - start != size) { > MessageUtils.trace("Size is > not match with actual read: > MessageID: " + (256 + msgID) + " size: " + size + > " actual read: " + (end - > start) + "\n"); > } > } > in.setCount(0); > > or similar (I've never coded java, so this might > be plain wrong). What it's > supposed to do is just read in the extra X bytes > of the packet into a buffer > and ignore them. The code was ok (there is just the declaration of int read missing), and fooly copying it failed with "out of array" exceptions. If the data read is longer than expected, the superflous bytes should be caught by the read thread loop: if (header == Packet.HEADER_CHAR) { ... dispatchMessage(_in.readByte(), size - 1, _in); } // If the first byte is not a packet HEADER (doh!) else { MessageUtils.trace(new String("" + (char) header + "(" + header + ")")); } After dispatching a too long message, the else print the superflous bytes and then, the next header should be read. Once again I have to understand the reading code, it will be clearer after. > > > [snip] > > > > 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 ? > > No, the CLC respects this protocol. The CLC will > always produce packets where > a header that says 'size=X' is followed by X > bytes of data. Always :-) > > In this case it's just that the options message > (199) has been extended by me > by a few bytes. So the core sends a header that > says 'size=123', but the EJG > only expects 108 bytes, because it doesn't know > about my extensions yet. But > instead of skipping the 15 bytes it doesn't know > what to do with it just > prints out a message and goes on parsing at those > unexpected bytes, expecting > a new packet header there. At least if I'm > correct. And that would > definitively be a bug in the Java client.... At first glance, i would say that it reads the 108 bytes, and pass the 15 bytes remaining that are not a "header byte". What can goes wrong is if it reads the header, the 108 bytes expected, and find a HEADER byte in the 15 remaining bytes. This could lead to read the 4 length byte and skip important data... I stop this mail, and go in the code. I'll keep you informed. Robin |
|
From: Tim <t....@ze...> - 2003-05-17 14:22:17
|
On Friday 16 May 2003 20:51, Robin wrote:
Hi,
> 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:
I had a quick look at CoreController.java in jc/src/com/mm/net/, and found
basically only the following issue:
* how does the EJC behave if the packet size doesn't match the size read?
(a) if read > packet size: not sure what happens. This case should not
happen though.
(b) if packet size > read: line 745 should show a message
"size is not match with actual read" (sic). The problem that I see is
that the EJC might not read in those 'superfluous' bytes, nor will it
skip those bytes. But maybe I'm just wrong :-)
A simple 3 lines here could resolve quite a few problems (see below).
> [MetaInputStream stuff:]
> 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).
Maybe we should leave that stuff alone then for now, and rather fix the stuff
as it is, that might be easier?
> 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).
yes, agreed. Just ignore my first mail to the list then :-)
> 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
aaah. The newer cores send an options message as one of the first messages
when the GUI connects. So if the GUI fails here, everything else will be
unlikely to work, as the EJG apparently does not re-sync the input stream to
the next packet header.
Try inserting this code in CoreController.java from line 735 and see if that
makes it work:
if (!processed) {
byte[] result = new byte[size];
int read = 0;
while (read < size)
read += in.read(result, read, size - read);
MessageUtils.trace(new String(result) + "\n");
}
else {
int end = in.getCount();
+ byte[] resttoignore = new byte[end-read+1];
+ while (read < size)
+ read += in.read(resttoignore, read, size - read);
if (end - start != size) {
MessageUtils.trace("Size is not match with actual read:
MessageID: " + (256 + msgID) + " size: " + size + " actual read: " + (end -
start) + "\n");
}
}
in.setCount(0);
or similar (I've never coded java, so this might be plain wrong). What it's
supposed to do is just read in the extra X bytes of the packet into a buffer
and ignore them.
> > [snip]
>
> 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 ?
No, the CLC respects this protocol. The CLC will always produce packets where
a header that says 'size=X' is followed by X bytes of data. Always :-)
In this case it's just that the options message (199) has been extended by me
by a few bytes. So the core sends a header that says 'size=123', but the EJG
only expects 108 bytes, because it doesn't know about my extensions yet. But
instead of skipping the 15 bytes it doesn't know what to do with it just
prints out a message and goes on parsing at those unexpected bytes, expecting
a new packet header there. At least if I'm correct. And that would
definitively be a bug in the Java client....
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
|
|
From: Tim <t....@ze...> - 2003-05-15 07:23:51
|
Another item for the TODO List:
How can the GUI detect an overnet core?
When the JavaGUI connects to the core, the core does not identify itself as an
overnet or eDonkey2000 core unfortunately. What I do in ed2k-gtk-gui is to
send an 'advanced command' "g" to the core, which should result in two
status messages from the core (ie. two line).
If one of those two lines starts like this:
ID: <32 hex digits, ie. 0-9,a-f,A-F>
then it's an overnet core. An eDonkey core would return something like
'ClientID: <foo>' I think (or something similar).
Note that you should not expect those two lines of output to arrive right away
after you've sent the command - the core might send some other status
messages before that. The only thing you know is that you get an answer and
that the answer comes after you've sent the "g" command, but that's about it,
so don't assume synchroneous communication.
The GUI needs to know whether it deals with an overnet core for various
reasons:
* the file meta data is slightly different in overnet IIRC (e.g. the records
data of the 'shared files' message and the 'new download' message will
look slightly different).
* the GUI must not under any circumstances send a search in overnet via
the 'search' protocol message. This will crash an overnet core (or at least
id did crash them in the past). At the moment only simple searches are
possible for the overnet command line client, e.g. only for words. Extra
search options won't work. Searches have to be sent to an overnet command
line client via the 'advanced command' protocol message only, e.g.:
s freebsd handbook
or
s linux
What will not work is sth like 's -Audio foo' (at least it didn't last time
I checked)
* overnet will return search results the way eDonkey returned 'extended'
search results (same protocol message), ie. one result per message.
When dealing with an overnet core, the GUI must not assume that it
will receive a 'proper' search results list before it receives 'extended'
results.
* overnet does not have an 'extend search' command. It's not needed.
That's all I can think of now. I'll check the details later.
cheers
-Tim
|
|
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: Tim-Philipp M. <ti...@ed...> - 2003-05-14 14:21:16
|
On Wednesday 14 May 2003 14:41, Robin wrote: Welcome to the two of us, hehe :-) this must be the smallest mailing list I've ever been subscribed to, but I suppose it makes sense to have these discussions in public, so it's archived on the sourceforge site, and you or others can draw on the wisdom that is going to be collected on this very list ;-) > > [Tim wrote earlier:] > >I'll think of some things that need to be done in the > >JavaGUI, and post them to the mailing list later or > >tomorrow, with as much detail as I can think of, > >so that you have something to start experimenting with. > > Thanks, what would be useful is a small list (hints) on > what had to be changed in gtk-gui to support the 0.47 core > versions. Maybe it won't be too difficult to add this > support, isn't it ? well, thing is that I don't have a very good memory, and that I usually keep adjusting the GUI to the current core cvs versions. Sometimes I don't even know when a new core comes out, so it's hard for me to pin down the exact changes that were necessary. Also, ed2k-gtk-gui has had overnet support for a while, so that might have something to do with it too. As I said, I'll think of things (and check the ed2k-gtk-gui source code) that I know need to be taken into account. > I'm not sure, but if i'm not wrong, the Controller was > working with the 0.47 core, and after upgrading to 0.48, > it stops working. I tried to clean the temp directory and > to relaunch the 0.47, and this didn't work anymore. (it could > be between 0.46 and 0.47, and it could be wrong, I don't > remember very well). > > So, any hint is welcome, if you don't have the time, I'll > inquire by myself...ah, just a thing that could help me to > start: > the first thing with the new core is that te > controller doesn't see that the core is connected to a server > thus prevent it to launche a search, do you remember if this > was the same thing with the gtk-gui, and what has to be > changed? ah, yes. I struggled with that as well, until someone else solved this. The eDonkey2000 core does not send an initial 'connected to' gui-core protocol message to the GUI when the GUI connects and the core is already connected to a server. However, it sends a normal 'status message' message with a text line that goes like this: Connected to: <IP> Apparently it always sends an IP even if it has the server name. I'm not sure if that is a space between the ':' and the IP or a tab, but that should be easy to figure out. So that should solve this problem - the GUI just needs to parse the status message protocol messages (CORE_STATUS_MSG, msg 180 decimal) for that string to know whether the core is connected or not. :-) More to come... Cheers -Tim |
1 message has been excluded from this view by a project administrator.