Please CC as I am currently not using my normal e-mail address. Van: [EMAIL PROTECTED] (Raphael Manfredi) > It's allowed. The ID is just an opaque string. It's just that seeing a > minus sign here makes me think that there might be parsing problems > later. Other PARQ implementations in other servents might use hexadecimal > GUIDs. Therefore, the ID must really be parsed back as an opaque string > in the client code: only the server must know the format of the IDs it > generates.
Well from my point of few. No matter what I put in the ID, the requesting client is required to treat it as a string. So a minus sign shouldn't matter. If a client won't implement it correctly it is there loss, not mine. The current PARQ implementation will handle all IDs equally as a string. However if it is really troublesome I don't mind changing it into a HEX code though. It won't break anything in my local code. > OK, the problem might be that the queues are not displayed in the GUI. > That's why it's harder to follow what's going on. Well, I think all 3 upload slots should be used even if there are only 2 queues filled. However, does there need to be a change in the GUI to display these queues? I don't think it is nice to have > 100 entries just displaying: "Upload queued in queue 1 at position 4 out of 315". However, perhaps it is nice to have something like: Queue 1: Contains 315 items of which 2 are currently being uploaded. Queue 2: Contains 0 items of which 0 are currently being uploaded. Queue 3: Contains 13 items of which 0 are currently being uploaded. > About PARQ persistence: I think we should do something I had not thought > about before: treat the current uploading slots as PERSISTENT: give them > a position and a "queue ID" so that they can be "restarted" by the > servent in case of a crash (via QUEUE). Also, a remote crash by the > downloading servent could be recovered by having that servent present the > necessary queue credentials that would perhaps not restore its upload > slot, but at least put him ahead in the queue. Unless we accept to > reserve slots upon startup for recovery during 5 minutes, say. > > To be able to do that, we have to enrich the reply we give to servents > that get a slot, so that they have a PARQ X-Queue and X-Queued > information as well. Does that makes sense? Is this is false good idea? I am in favor of this, and the PARQ code actually already does a little bit like that. When the server crashes, goes offline or something like that. All queues are restored on start of gtkg. This includes the 'items' which were currently being uploaded. So when GTKG starts again, those items are queued again at position 1 so they will be the first to start again (if re-requested of course). It doesn't prevent a client losing its position when the client itself disconnects. If gtkg should also handle this, it should make sure the ID won't be re-used for another file than the one it was originally downloading. Perhaps the ID should completly be ignored when it got an upload slot and the queued item should be looked up as it does with non PARQ enabled clients, that is by IP and requested filename. Small note for myself: I guess I should not timeout queued items when gtkg detect it is currently offline. PS. I am in favor for making the expire time very large. IE, one week. So a simple modem user can keep its position even when it can only connect in the evening hours, so it won't loose its upload slot during the rest of the day. Not sure if I want to move the queued item up in the PARQ while the client is not connected though... (I don't think it is fair for those who keep there client running 24/7) - Jeroen -- Excessive login or logout messages are a sure sign of senility. ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
