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 ;-) |