dcgui & $Supports CHUNK

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Locked
GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

dcgui & $Supports CHUNK

Post by GargoyleMT » 2003-04-11 20:55

I didn't see much reaction to it, but Mathias posted a while back saying how he implemented an extension (offered in $Supports) for dcgui to help multi-source downloading: CHUNK. From his post, the parameters to $Get are extended: "filename$start-position$chunk-size".

distiller should take note of this, as pDC++ would be a good place for this feature to turn up first.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-11 22:24

Hey GargoyleMT,

I was just wondering how much use an actual $Support feature would be for this. Why can't the client just disconnect from the user once they have gotten the size of the chunk they needed? I would like to understand the logic of having a whole new command when it isn't needed (seems to me, that's why I want to understand).

~Moch

distiller
Posts: 66
Joined: 2003-01-05 18:05
Location: Sweden
Contact:

Post by distiller » 2003-04-12 01:07

As the pDC developer I can tell you the need for this... =)

When a segment is done and you disconnect you may loose the slot. Very undesireable. =)

Gargoyle! I have my new motherboard in the mail. Not only did I get a new one by guarantee, I got a better model as well as mine was no longer available (hurray!!) =) I'll merge pDC with 0.241 later this week and have a look at "chunk". But there aren't that many dcgui users and getzblock will probably be the better way anyway. =)

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-12 07:52

That's what some of the people on the devel hub said, that GetZBlock would do the and thing and be better. But this is a pre-existing feature that probably wouldn't be much coding (BufferedSocket::threadSendFile), and compatibility ain't a bad thing. Especially if zlib compression ends up taking a fair amout of CPU usage. (like I imagine it could for people on 10 or 100 mbit lines) Plus GetZBlock has had code in the client for 4 months now, and it's still not enabled.

It's the next best thing to a $Cancel command (to abort a transfer in progress).

And Moch, it's useful because you might end up getting, say 1/10th of a file from the sources you have, but after that chunk is finished, you might need to retrieve another chunk - which probably isn't the chunk right after the one you transferred. Or if we have hashes, part of the segment might need to be retransferred because of corruption. Fine grained control is nice.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-12 13:49

Perhaps I am being to over critical... but....

Yeah it would be nice to have a guaranteed spot for another chunk, however the idea of being able to get chunks is that you can get one file from multiple users. Saying, Oh... and I am going to continue to take up a slot because you have more chunks that I don't have and I am not connected to anyone else to get that chunks is like saying (on a smaller scale) I have more files in my queue that I am not getting from anyone else, so PLEASE don't give my slot to someone else and let me continue my other file downloads from you.

I understand you are looking it at the point that it is still the same file. However, I am looking at it from the point that all sessions of getting files in a slot is just a broder term of getting a chunk of data.. plus with chunks that implys you are getting the file from multiple people.

It seems to me that it is asking a lot to have the ability to download a file from multiple people and continuously hog a slot on each of those people till the whole file is done.

Perhaps the slot that is doing a chunk transfer should actually queue up people seeking chunks from the same file and do a rounf robin with giving out chunks. That seems much more fair to the DC community. However, that we know is a whole diffrent issue (and thread I beleive). *L*

As I said at the beginning I am just being critical, I know it makes since to have someone to continue to ask for more chunks from the same file.. Just because a "chunk size" doesn't seem to have to be a standard size. Perhaps the client could deciide how much data (all together) a client should get before they disconnect them to allow someone else a chance at the slot. This actually seems like a reasonable thing even if you didn't have chunks ;) *L* Ok yes, now I am just being silly.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-12 14:21

You seem to always converse and post in a devil's advocate critical way. I'll try not to take it personally. ;-)


The DC system currently does operate on a principle of "PLEASE don't give my slot to someone else and let me continue my other file downloads from you". :-) Slots are permanent, essentially, in this system. I guess your concern is that people will potentially be using more slots for longer. If so, sarf wrote a pretty decent rebuttal, and I agree with his logic.

Being able to request chunks will enable the client to be the most efficient in using multiple sources - requesting just enough chunks from each user so that they all end at the same time.

Disconnecting when you get a chunk from a file (like pDC does) is borderline abusive, in my opinion. A protocol extension, in $Supports, is the proper way to do this, since the DC protocol doesn't have support for cancelling a transfer in progress.


I do agree with your last paragraph, since I am also unhappy with the lack of a queue in DC++. Some people might want a byte limit and others a time limit... I'd like more rotation among the slots I share - probably because I'm on a 128kbit upstream not a 10mbit one. ;-)

distiller
Posts: 66
Joined: 2003-01-05 18:05
Location: Sweden
Contact:

Post by distiller » 2003-04-12 15:53

It's possible to use zero compression with zlib, so it shouldn't take much CPU. I'll try to implement chunk anyway, but it requires coding in many different places of DC++ and that will take quite some time... =)

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-04-13 08:01

GargoyleMT wrote: Disconnecting when you get a chunk from a file (like pDC does) is borderline abusive, in my opinion. A protocol extension, in $Supports, is the proper way to do this, since the DC protocol doesn't have support for cancelling a transfer in progress.
According to the Direct Connect Protocol Documentation, there is a $Canceled command. I'm not certain what it really does, but couldn't it at least be used instead of implementing a new Chunk-feature? In this way, new clients would be able to disconnect gracefully, and older clients would probably still work, but the slot would be lost (or?).

I see another problem with using a new CHUNK argument to the $Send command.. Does the client always know how big a chunk it needs when requesting the file? I would rather think that the most common scenario is that the client first tries to download the entire file from the first source. Then, if a new source is found, the client starts a new download beginning in the middle (or wherever it finds most suitable). When the first source reaches the position of the second download, it sends a $Canceled command and then (if still given the slot) tries to get a new chunk (beginning perhaps at half of the remaining bytes).
Or am I completely wrong here?

/Anders

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-04-13 08:35

dc++ isn't aware of the $Canceled command (especially considering that dc++ doesn't read while writing). but this command could be used yes.
andlju wrote:Does the client always know how big a chunk it needs when requesting the file?
the complete file would be downloaded in chunks of (predefined) chunksize. the extra $Get's involved shouldn't be a problem.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

CarXor
Posts: 11
Joined: 2003-04-07 18:09

Post by CarXor » 2003-04-13 08:53

I had a pretty good post but it got lost (no post mode specified), so here is just the big picture:

Both zlib and chunk and sha1, md4, md5, crc ... could live side-by-side easily with the $Supports

It's like this:

Client A sends: "$Key <key>|$Supports zlib md4 md5 chunk crc|$Get <filename>$resume_pos$chunk|"

if Client B does not understand, it will respond normaly with the $FileLength
but if it does understand, it will answer what he did:

Client B sends: "$Supports zlib=4 md5=<base64 hash> chunk|$FileLength <len>|


this means that client B is compressing the data using zlib compression 4, the md5 of the full file is the hash in base64 and the data is the requested chunk

Note that should be the uploader to determine if zlib compression is available and the compression ratio. This will improve the CPU usage in files that are already compressed (mp3, jpg, divx, zip, arj, etc...) and save bandwidth in files that can be well compressed (html, txt, dll,...).

The uploader also decides which hash is to be selected from the Client A options. Client B can choose to provide more than one hash.

According to the chunk command, it can get implemented, but if Client B expectes a $send every 40k, is there a real need for this?

In general, do you think this will work?

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-04-13 09:07

well Supports is currently part of the handshake,
so currently it won't work like you suggest.

first both clients tell their supported features,
and first after that the transfer commands can be sent
(e.g. first both need to agree on BZList before a Get MyList.bz2 command can be issued)
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-13 09:29

From past discussions, I think it's best to wait for tiger tree hashes to land in the client before inventing new schemes. Then build in a $Supports GetMetadata (or something similar). The metadata would be a little XML stucture, and would include the full tiger tree (if it had been hashed by that point), for incremental verfication. The downloading client would then get a chunk (through extended Get syntax or GetZBlock), and use its own logic afterwards to request corrupted chunks or additional chunks.

And thanks (!!!) for the pointer about $Cancel (strings on the OSX version turns that up, not $Cancelled). I'm still trying to track down NeoLite for decompressing the win32 NMDC. Apparently they were gobbled up by MacAfee a while back...

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-04-13 11:03

GargoyleMT wrote: And thanks (!!!) for the pointer about $Cancel (strings on the OSX version turns that up, not $Cancelled). I'm still trying to track down NeoLite for decompressing the win32 NMDC. Apparently they were gobbled up by MacAfee a while back...
Well, it seems like we could forget about using that command in order to keep the slot anyway.. DC++ doesn't even listen for incoming messages, and I tried NMDC - didn't respond, neither $Cancel, $Cancelled nor $Canceled worked.. :?

/Anders

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-13 12:24

Well, it seems to work like this, from what I've seen:

(existing transfer - D = downloader U = uploader)
D>U "$Cancel"
U>D Keeps sending (presumably queued) data (8kb x 4 in the case I watched)
D>U keeps ACKing data
U>D "$Canceled" (in its own packet)

Then the connection is idle.

For someone uploading to someone else, the only option is to close the connection, you can't request a Cancel unless you're the downloader... Or so it seems to me.

(This is between two NMDCs - 1.0 Preview 9.1 on windows.)

sandos
Posts: 186
Joined: 2003-01-05 10:16
Contact:

Post by sandos » 2003-04-13 13:49

GargoyleMT wrote:Well, it seems to work like this, from what I've seen:

(existing transfer - D = downloader U = uploader)
D>U "$Cancel"
U>D Keeps sending (presumably queued) data (8kb x 4 in the case I watched)
D>U keeps ACKing data
U>D "$Canceled" (in its own packet)
This is not good. Tcp streams are just that: streams. You should never rely on packet boundaries. Say the file actually consists of "$Canceled" repeated 10000 times, this makes it hard to know which one is actually a command, and not data.

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-04-13 14:06

sandos wrote: This is not good. Tcp streams are just that: streams. You should never rely on packet boundaries. Say the file actually consists of "$Canceled" repeated 10000 times, this makes it hard to know which one is actually a command, and not data.
Well, after the downloader has sent $Cancel, I guess it should simply discard any further packets, and just look for $Canceled.. I still haven't been able to reproduce this behaviour though, but I'm trying to do it between my own client and NMDC, so I guess I'm doing it the wrong way.. :-(

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-13 14:51

sandos wrote:This is not good. Tcp streams are just that: streams. You should never rely on packet boundaries. Say the file actually consists of "$Canceled" repeated 10000 times, this makes it hard to know which one is actually a command, and not data.
Well, I made a file, where $Canceled was at 0 offset every 1024 bytes. It didn't phase DirectConnect. Although it's stateless in other areas, the downloading client must only look for $Canceled after it sends $Cancel. Etheral showed me that every batch (it globs into 8kb chunks it looks like), there's a $Canceled at the beginning of the byte.

Hmm, I see what you mean.

Canceling that transfer did nothing to NMDC. Both clients saw the connection go idle. The bytes I used for filler were \0s, btw. I guess it checks to make sure the data packet consists only for "$Canceled" and that the size matches up. (So you could only screw it up by having a trailing 9 bytes on the file, falling on a 8192 boundary that consisted of "$Canceled") Or it robustly ignores the "wrong" data if it picks up on the $Canceled at the beginning of the 8192 block of data that it's receiving.

In either case, does your objection still stand?

sandos
Posts: 186
Joined: 2003-01-05 10:16
Contact:

Post by sandos » 2003-04-14 02:29

GargoyleMT wrote:
sandos wrote:This is not good. Tcp streams are just that: streams. You should never rely on packet boundaries. Say the file actually consists of "$Canceled" repeated 10000 times, this makes it hard to know which one is actually a command, and not data.
Well, I made a file, where $Canceled was at 0 offset every 1024 bytes. It didn't phase DirectConnect. Although it's stateless in other areas, the downloading client must only look for $Canceled after it sends $Cancel. Etheral showed me that every batch (it globs into 8kb chunks it looks like), there's a $Canceled at the beginning of the byte.

Hmm, I see what you mean.

Canceling that transfer did nothing to NMDC. Both clients saw the connection go idle. The bytes I used for filler were \0s, btw. I guess it checks to make sure the data packet consists only for "$Canceled" and that the size matches up. (So you could only screw it up by having a trailing 9 bytes on the file, falling on a 8192 boundary that consisted of "$Canceled") Or it robustly ignores the "wrong" data if it picks up on the $Canceled at the beginning of the 8192 block of data that it's receiving.

In either case, does your objection still stand?
I dont think its done properly but, yeah, it works.

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2003-04-14 06:07

A few comments...
First, GetZBlock is not enabled for many reasons, but mainly because I can't test it properly, and it's the kind of feature that really should work when distributed to the public...second is that I can't decide how to limit it...it takes CPU from the uploader so a reasonable way for him/her to limit it is needed...
Currently, if I remember the numbers correctly, it compressed at about 2mb/sec at level 6, and 6-7 mb/sec at level 0 (just adler32 computing) on my 600mhz portable...I didn't look into it in detail, and it was a local transfer, so the receiving and sending was done on the same computer...somebody with a proper lan should experiment more...
GetZBlock will obviously be followed by a GetBlock that has the same semantics but without the compression/adler32...whether this leads to segmented downloading or not, I haven't still decided, but I guess it opens the door...
$Cancel will not make it to DC++, it's a stupid and meaningless way of doing things. DC++ does receive during send, but silently ignores what's sent in most cases. $Send every x bytes is another stupidity that Hess invented, but thought the better of (if I remember things correctly) and removed in some nmdc version...(the reason for adding it evades me...an extra ACK, as if the TCP/IP one wouldn't be enough?)

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-04-14 06:23

arnetheduck wrote:$Cancel will not make it to DC++, it's a stupid and meaningless way of doing things. DC++ does receive during send, but silently ignores what's sent in most cases.
Just a bit curious, why is $Cancel such a bad command? I agree that it may not be the best way of handling multiple source downloads, but is it so bad to be able to cancel the current download without losing the slot?

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-04-14 12:21

andlju wrote: Well, after the downloader has sent $Cancel, I guess it should simply discard any further packets, and just look for $Canceled.. I still haven't been able to reproduce this behaviour though, but I'm trying to do it between my own client and NMDC, so I guess I'm doing it the wrong way.. :-(
I know, it looks like I'm the only one that likes this command, but if anyone else is interested, I found out what I did wrong..

Silly me, I thought that the $Cancel command should be sent as usual, with a trailing |. Turns out that the pipe isn't used, neither with $Cancel, nor with $Canceled..
Oh joy.. Once again, the protocol is able to astonish me..! Had to create an "OmitEndChar" property in my Command class.. :?

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-04-14 13:07

Why is $Cancel is a bad idea…
When transferring a block of data, the block should be a predefined size. Let’s say 64k. If $Cancel is used by the downloader to tell the sender that it's reached the end of the block, chances are that more that 64k of data would have been sent. This is a waste of bandwidth...

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-04-14 13:19

mo wrote:Why is $Cancel is a bad idea…
When transferring a block of data, the block should be a predefined size. Let’s say 64k. If $Cancel is used by the downloader to tell the sender that it's reached the end of the block, chances are that more that 64k of data would have been sent. This is a waste of bandwidth...
You're right, of course. I don't think it's a good way of doing multiple source download (at least not as the main alternative). However, I still don't see why the command should be avoided totally. I like the idea of beeing able to abort a download without losing the slot, and without an abrupt disconnect. In addition, the command could be used for multiple source downloads when no other means are implemented by the uploading client.

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-04-14 14:24

I think the point is that $Cancel functionality doesn't currently exist.

If downloading chunks of data is going to be supported, it will be done the most efficient and programmatically sound way. Adding support for a hacked way of downloading chunks is not good.

Your argument that someone should be able to stop a download, mid transfer, without losing your slot would be a debatable feature. Personally, I don't think I would like that feature to be implemented.
If you made a mistake by downloading the wrong file, and want to change to something else, I think losing your slot is the correct way to go. Chances are you will get it back anyway.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-14 18:35

You're not the only one who likes it. If it's not an ugly hack to DC++, I'll probably, later rather than sooner, test out a patch for it.

Since I help keep order on the bug and RFE tracker on sf.net, I've seen at least a couple (reasonable) feature requests that can be solved if this gets implemented. Mostly it's something like: alternate search finds sources on a new user. Downloader wants to get his/her list to check for more. Downloader has to wait, or close the transfer and force a reconnect, to get the list.

I don't think it -should- be used for multi-source downloading, I think it should be included for NMDC compatibility, and because it's "nifty" :)

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2003-04-15 06:50

But it won't because it's ugly. Sending things in the middle of the stream is not nice, if it was to be done, it should have been done with a separate control connection, a la ftp...hm, someone could of course check if tcp out-of-band data could be used for this? That would be at least a semi-clean solution...

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-04-15 08:10

Well.. the uploader should never be able to send the $Cancel (or $Canceled) message, that would be reeally bad. However, I still don't see what's soo bad about the downloader sending a message while receiving data?
But, I have to admit that I'm not that experienced with socket programming, so maybe I'm just stupid to argue with the master.. Please enlighten me!

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-15 11:16

Rather than argue, perhaps it's best to see if it can be integrated in an elegant way. Perhaps if received in BufferedSocket::threadSendFile, it can throw an exception, and be caught at an appropriate place for bringing the connection back to an idle state (not sure, I haven't done throwing in C++... ever). The BufferedSocket::threadRead (?) is probably the inelegant part, as you'll have to toss data until you receive the $Canceled (or not... ?). And the $Canceled won't be handled in the place where the other client to client commands are (plus it's in a different format - no |).

Of course, this is idle speculation, and I really prefer not to talk without having a good understanding about the details (which Arne does, it's his code)... :(

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2003-04-17 08:48

Because it's undesirable to abort a stream using an unescapable string as abort sequence, the file might (however low the probability would be...but a description of the dc protocol is the first thing that springs to mind =) contain the affected data sequence...block sizes can't be trusted, 1) there's no such thing as a block in TCP, 2) different apps/versions use different read from disk block sizes, 3) it has nothing to do with c++ exceptions, it's a pure protocol thing...
Look at any decent protocol/grammar, you'll see that any "magic" sequences are escapable (c++ strings is a perfect example, using \ as escape character if there could be any problems...)

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-04-18 11:08

I think you're sort of missing the point (or maybe I am..). The $Cancel command should _never_ be sent by the uploader - i.e. there is no risk of the command beeing sent in the middle of a file stream.

The flow would be like this:

D>U: $Send
U>D: file stream [D saves to disk and doesn't care about any "commands"]
D>U: $Cancel [D stops saving to disk and starts to check for $Canceled commands]
U>D: maybe a few more bytes of file stream [ignored by D]
U>D: $Canceled

distiller
Posts: 66
Joined: 2003-01-05 18:05
Location: Sweden
Contact:

Post by distiller » 2003-04-18 11:13

Excellent point andlju. =) But does NMDC listen to this command? Then It's time I implement it nicely in pDC and send patch to Arne if he wants it. =)

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-04-18 11:21

Yes, NMDC listens to this command, and it work's quite nicely actually. I've also implemented it in my own client already (but it's not DC++ derived, so I don't have any code that could be used as a patch).

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-18 11:35

NMDC v1.1.0 for OS X doesn't support $Cancel. There's no "Canceled" in the program, but there's a message saying that $Cancel isn't supported. I haven't figured out how to get that message, though.

distiller
Posts: 66
Joined: 2003-01-05 18:05
Location: Sweden
Contact:

Post by distiller » 2003-04-19 06:49

How many MAC users are there with NMDC?? =) They'll be using DC++ anyway once/if the GUI get's ported to wxWindows, I hope...

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2003-04-19 11:33

andlju wrote: U>D: maybe a few more bytes of file stream [ignored by D]
U>D: $Canceled
You're missing the point. It's the maybe that annoys me...sure, it would work more or less, but I don't like it as a technical solution, and therefore DC++ won't have it. As much as I don't care about protocol in real life, I do care about it when it comes to computer science, and I do not like protocols with maybe's in it...

distiller
Posts: 66
Joined: 2003-01-05 18:05
Location: Sweden
Contact:

Post by distiller » 2003-04-21 12:01

Well, how is it handled currently? Just close the TCP connection?
Don't know if that is very nice for the sender. It obviously works, but what's the difference between:

1: Waiting for the "$canceled" a couple of bytes and then drop the connection gracefully, do it the 2nd way if no "$canceled" is recieved.
2: Just drop the connection

What does the networking guide say about the matter? What happens to the sender when the reciever just drops the connection? And why is 8 KBx4 of "maybe" a problem? To discard the bytes is easy. To drop the connection if no "$canceled" is recieved shouldn't be too hard and does improve the possibility of implementing "find the fastest source available" as noted in this thread.

taltamir
Posts: 9
Joined: 2003-05-13 17:41
Location: Hell (Coppell, Texas, U.S.A.)
Contact:

Post by taltamir » 2003-05-19 23:14

this is all kidna confusing... is it implemented or not?? can I while using DC type a command that will cancel a download but keep the connection? what command is that?
I do not have a superman complex; for I am God, not superman.

distiller
Posts: 66
Joined: 2003-01-05 18:05
Location: Sweden
Contact:

Post by distiller » 2003-05-20 05:24

No ther is no such function in DC++ or NMDC at the moment, DCGUI sports it though.

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-05-20 05:27

It actually works with NMDC as well, but both clients have to support it.. And, it is only the downloader who can initiate a Cancel.

distiller
Posts: 66
Joined: 2003-01-05 18:05
Location: Sweden
Contact:

Post by distiller » 2003-05-21 19:48

and not all versions of NMDC supports it, not the mac version anyway.

taltamir
Posts: 9
Joined: 2003-05-13 17:41
Location: Hell (Coppell, Texas, U.S.A.)
Contact:

Post by taltamir » 2003-05-22 21:09

i see.. thanks
I do not have a superman complex; for I am God, not superman.

Locked