The recommended startup script has evolved in time, just update your old nodes.
I changed my script just last month to switch over to Polygon. What else has changed?
You need to specify tcp and udp in the startup parameters, check out my previous post.
beast
Do you want to learn? or earn a side income. In the first case you’re in the right place in the second case you’re not going to get rich quick.
Nope. The node that updated automatically has the same config file as the others and that is currently reporting QUIC as ok.
This one looks perfectly fine so far.
If they both have tcp/udp specified try to restart the one showing miconfigured.
I’ve posted in other threads on this topic…
QUIC is unsuitable for my LAN as well as my ISP. From the numerous technical papers that I’ve read over the course of the last 2 years, it’s unclear to me that there’s any benefit whatsoever for Storj as a network to transition to QUIC as a primary transport protocol.
I’ve tried running QUIC on my IPFS nodes which have incorporated it since before v0.10 … the result was a flooded LAN with UDP packets and being rate limited by my ISP.
When researching why… I found several competing papers on QUIC.
After reading through several, I simply disabled QUIC on IPFS and 100% of my problems with my LAN and my ISP disappeared.
I’m not running QUIC as a default transport on high traffic incoming and outgoing p2p services.
End.of.Story.
It’s more trouble than it’s worth.
I have yet to have anyone provide a detailed evidence based reason for switching from TCP to QUIC… and since my LAN and ISP are unsuited to running such protocols, I will simply stop providing service if Storj switches completely to QUIC.
It’s all good.
I like Storj as a project, and like QUIC as a concept… but will not run QUIC as it is impractical and thus will abandon Storj because it will become too much trouble.
It will be interesting to see if QUIC works well on low resource computing platforms… since most technical papers suggest that it won’t due to the need for user space resources to perform all the functions that can be offloaded to dedicated hardware NIC adapters with TCP.
But, I guess we’re all Google super computing platforms now…
minus IPv6 ---- because Google doesn’t like to reveal network topology and prefers flooding CGNAT clients with UDP packets instead.
Ah! Well… it’s all fun and games anyway.
Sorry I haven’t seen them and I’m unfamiliar with the QUIC protocol, but I don’t see how an external protocol would mess up my LAN. I could understand some ISP’s would block some protocols on residential customer. Its why I advised you to use a rented server, they won’t blocs any protocol and won’t mess up your LAN. If you’re looking around for data center processor they can be very cheap, like $4/m otherwise in the $15/m it might be in a foreign country (I don’t know where you live) a good way to learn to run remote systems, ssh, x2go or others.
I’m not familiar with IPFS either but I still don’t see how a single redirected port 28967 in your router would mess up your LAN.
If you’re an IT professional you should spend some more time learning about ssh redirection and other stuff like that, but if its just an hobby I understand your frustration.
Anyway thanks for your circumstances answer.
Quick summary on QUIC…
QUIC is a protocol developed by Google which uses UDP packets rather than TCP as transport of HTTP data.
- The data and headers are encrypted vs. just the data for TCP.
- The encryption is end-to-end and does not rely on Certificate Authorities.
- Connections include a unique identifier which follows the connection.
- All protocol functions are implemented in user space to avoid long lead times in implementation in hardware - the CPU is replacing ASICs… think CPU graphics card vs. dedicated GPU or winmodem for the grey beards.
- Google claims significant increases in throughput over TCP.
- The protocol is open source and includes library implementation in Google’s go language … which is what storj’s service is written in…
However, there are a significant number of research papers that show that QUIC is not necessarily more efficient bandwidth wise and may be much less performant in some circumstances. There is evidence that QUIC performs very well in a large data center supplying lots of clients lots of data… There is also evidence that QUIC may perform far worse that TCP on networks with TCP and QUIC running side by side and/or networks where a low resource server is supplying many connections to clients accessing large numbers of small data pieces…
In short… there are several papers that indicate QUIC may horribly break Storj.
I also run several IPFS nodes. IPFS includes the ability to utilize QUIC and that is the default protocol out of the box. I tried running my IPFS nodes using QUIC, but ran into problems… disabled QUIC, and everything is working just fine.
All things considered, it seems like implementing QUIC for SNO traffic is a fix for a problem that doesn’t exist…
As to ssh, x2go, vnc, openvpn, running VPS, spinning up Linodes, or Droplets, or tunneling IPv6 through IPv4, running email servers, web servers, cutting my own toenails… I’ve done those things.
UDP is a pernicious protocol to run on consumer ISP backed services. I imagine Storj will have enough nodes that work fine with QUIC… but, I will not be one of them.
1 Like
I have the Problem that I can’t open UDP and TCP on the same port on my router. I can only use one port for TCP and a different for UDP. Is there any workaround for that?
Try to clear cache and cookies in the browser for this particular node.
1 Like
Hello @Deepcuts ,
Welcome to the forum!
Please try to restart the service (or the container, if it’s a docker).
If it’s still shows as misconfigured this is probably true, please check requirements: QUIC requirements - Node Operator
Now my node is OK. Problem that i had is that i did not have UDP IPv4 Port forwarding on my home router.
Then run Restart-service storjenode on PowerShell is a must!
Same steps that DrGuns4Hands said:
On my router I could open TCP & UDP with one rule. When creating the rule i have 3 options TCP, UDP or TCP&UDP so maybe you have the same?!
For me, I had to remove some redundant rules from Windows firewall to make it work.
Yes, use the TCP&UDP option for the rule, so it is both together.
thx - that fixed my problem as well!
Hello @Alexey
All my nodes were TCP only.
Noticed the error message about quick and I added the UDP rule also, expecting the node to check again in the near future. None of them did, even after several hours.
Just a simple container restart solved the issue without any other tweaks to command line.
Thus, I stick to my statement: error on storj part.
To me it looks like the node checks QUICK only on startup and if it considers it to be not accesible, it never checks again.
Thanks for the link. It looks like they are mostly testing sustained load or video streaming and not the many small connections Storj deals with. They’re also looking from the client side, which I’m not sure, but may impact findings as well. Storage nodes are technically the server side.
I think your IPFS example is also quite a different scenario, since as far as I’m aware IPFS downloads full files from a single source. So there you have more sustained loads as well. Please correct me if I’m wrong though. I’m not that familiar with IPFS yet.
We we can all hope of course. But I would say I’m not very hopeful. There is a lot of market effect in play here and if running a node becomes super profitable, it will simply attract a lot more node operators. Which in turn lowers profitability per node. I’m sure it will get a bit better but at the moment we see maybe 5% of that kind of bandwidth usage (assuming single IP) and I doubt we’ll ever see a x20 increase.
CTRL+F5 usually does the trick. Otherwise clear browser cache.
Probably not since an update already restarts the node.
You don’t think it’s even worth a try?
Not all QUIC implementations are made equal…
It wasn’t really intended to be. It mostly saves on handshakes which impact latency or time to first byte. In a setup with many connections like Storj, that impact is amplified.
That doesn’t invalidate your concerns, but any test that talks about bandwidth improvement is kind of missing the point of QUIC if you ask me.
Hard disagree. For customers small file performance is really slow in large part due to the many connections that all need to wait for longer handshakes. QUIC is well suited to help with that if done right. Customer performance, specifically latency and small file performance is a problem that DOES exist. It’s just not a problem you are experiencing from the SNO side as you get paid either way.
And I feel like I should mention… nobody else has yet complained about any problem with Storj’s QUIC or UDP implementation. I fear you may be excluding the possibility based on theoretical fears that may never come to pass. Of course we probably haven’t seen high loads on QUIC yet, but I don’t see why you wouldn’t at least give it a try if it would even become mandatory. You can always quit if it causes problems.
2 Likes