# Drpc stream terminated by sending error during download **URL:** \ **Category:** troubleshooting\ **Created:** [October 31, 2019, 9:13pm UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459 "2019-10-31T21:13:20Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![eagleye](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/eagleye/32/71_2.png) [@eagleye](https://forum.storj.io/u/eagleye)\ **Post date:** [October 31, 2019, 9:13pm UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459/1 "2019-10-31T21:13:21Z")
This error happens with files that repeat download. Prior to 24.5 the file download was fine every time. In the beginning certain files that repeat downloads worked fine, but recently I get the drpc stream terminated by sending error during download. What is the problem or is this standard testing. Never saw it before this most recent release. does it affect the node at all? ---
**Author:** ![Egon](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/egon/32/67_2.png) [@Egon](https://forum.storj.io/u/Egon)\ **Post date:** [November 1, 2019, 10:36am UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459/2 "2019-11-01T10:36:15Z")
Yes, this is normal for the time-being. We are testing and implementing a more robust and less resource-hungry communication. The errors are to be expected when either side unexpectedly terminates the connection (e.g. uplink reaches the necessary threshold or network drops or some firewall cuts the connection). Unfortunately, we haven’t yet managed to make the errors more descriptive. ---
**Author:** ![milaas](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/milaas/32/60_2.png) [@milaas](https://forum.storj.io/u/milaas)\ **Post date:** [November 13, 2019, 8:50pm UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459/3 "2019-11-13T20:50:19Z")
hi there, near half of my downloads failed. that’s my error message: “GET”, “error”: “piecestore: piecestore protocol: drpc: stream terminated by sending error”, “errorVerbose”: “piecestore: piecestore protocol: drpc: stream terminated by sending error\n\[tstorj.io/drpc/drpcstream.(\*Stream](http://tstorj.io/drpc/drpcstream.(*Stream)).SendError:261\n\[tstorj.io/drpc/drpcmanager.(\*Manager](http://tstorj.io/drpc/drpcmanager.(*Manager)).manageStream:224”} * * * ========== DOWNLOAD ========== Successful: 64598 Failed: 30145 Success Rate: 68.182% ---- some days ago everything was allright. if somebody has help thanks… best m ---
**Author:** ![milaas](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/milaas/32/60_2.png) [@milaas](https://forum.storj.io/u/milaas)\ **Post date:** [November 13, 2019, 8:54pm UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459/4 "2019-11-13T20:54:34Z")
maybe this (config.yaml): # how many concurrent requests are allowed, before uploads are rejected. storage2.max-concurrent-requests: 500 ---
**Author:** ![kevink](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/kevink/32/6077_2.png) [@kevink](https://forum.storj.io/u/kevink)\ **Post date:** [November 13, 2019, 9:09pm UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459/5 "2019-11-13T21:09:20Z")
This is for uploads (and not needed anymore), while your problem is with downloads. Maybe your node is too slow to handle all download requests or there is too much other load or too slow internet? ---
**Author:** ![BrightSilence](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/brightsilence/32/6048_2.png) [@BrightSilence](https://forum.storj.io/u/BrightSilence)\ **Post date:** [November 13, 2019, 10:24pm UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459/6 "2019-11-13T22:24:35Z")
500 was a ridiculous number to set to begin with, but as posted elsewhere, you should remove this setting now. With the new drpc implementation it’s unlimited by default and that should be just fine for almost all implementations. ---
**Author:** ![Odmin](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/odmin/32/92_2.png) [@Odmin](https://forum.storj.io/u/Odmin)\ **Post date:** [November 14, 2019, 6:08am UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459/7 "2019-11-14T06:08:44Z")
Look into [my post here](https://forum.storj.io/t/changelog-v0-25-1/2517/2), I think something go wrong… Also, I tried set `storage2.max-concurrent-requests: 0` (unlimited like on git commit) but it also not working, so only way at this moment is set very high number of concurrent connections. ---
**Author:** ![BrightSilence](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/brightsilence/32/6048_2.png) [@BrightSilence](https://forum.storj.io/u/BrightSilence)\ **Post date:** [November 14, 2019, 6:52am UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459/8 "2019-11-14T06:52:13Z")
I saw that but thought that was prior to v0.25.1. I see now that you confirmed it persists. I still maintain that any setting over 50 is pretty crazy. If you still hit the limits at 50 it’s probably a bad idea to raise it further and lowering might actually be a better idea to get fewer failed transfers. ---
**Author:** ![Odmin](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/odmin/32/92_2.png) [@Odmin](https://forum.storj.io/u/Odmin)\ **Post date:** [November 14, 2019, 7:09am UTC](https://forum.storj.io/t/drpc-stream-terminated-by-sending-error-during-download/2459/9 "2019-11-14T07:09:15Z")
> [@BrightSilence](#): > > I still maintain that any setting over 50 is pretty crazy. If you still hit the limits at 50 it’s probably a bad idea to raise it further and lowering might actually be a better idea to get fewer failed transfers. I completely agree with you. My proposition set very high numbers basen only on reccomendation in changelog: > [@Changelog v0.25.1](https://forum.storj.io/t/changelog-v0-25-1/2517/1): > > **Remove default concurrency limit** > > > By default a storage node had a limit of 6 concurrent transfers and will reject additional uploads until one of the ongoing transfers is finished. We believe with dRPC the limit is not needed anymore. By default the storage nodes will now take as many uploads as they can. You can still set the limit in your config file like before. Removing it from the config will reset it to the new default value. > > [Changelog v0.24.5](https://forum.storj.io/t/changelog-v0-24-5/2420) > > Last release only halve of that change was released. This time the change is real. In addition to that we also increase the audit timeout from 25s to 5 minutes to avoid disqualifications for responding too slow. If you haven’t already **please remove any limit you might have set in your config file**. We want to test the limits of dRPC. So I reported than this change is not working and we still have a limit on **v.0.25.1** > [@Changelog v0.25.1](https://forum.storj.io/t/changelog-v0-25-1/2517/2): > > I think limit is still persisting (I removed from config `storage2.max-concurrent-requests` ) and after storagenode upgraded to latest version see this on log: > > `docker logs storagenode 2>&1 | grep rejected` > 2019-11-07T20:01:27.060Z ERROR piecestore upload rejected, too many requests {“live requests”: 9} > 2019-11-07T20:01:28.599Z ERROR piecestore upload rejected, too many requests {“live requests”: 9} > 2019-11-07T20:01:30.996Z ERROR piecestore upload rejected, too many requests {“live requests”: 8} > 2019-11-07T20:02:54.721Z ERROR piecestore upload rejected, too many requests {“live requests”: 8} > 2019-11-07T20:12:28.007Z ERROR piecestore upload rejected, too many requests {“live requests”: 8} > 2019-11-07T20:12:28.461Z ERROR piecestore upload rejected, too many requests {“live requests”: 8}