You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Keep in mind, I am still not 100% if this is the issue.
Making my base64 smaller (changing the quality of the image) fixed the issue, AKA smaller base64 string
Version Infos
What version of this package are you using?
simple-peer@9.11.1
What operating system, Node.js, and npm version?
Node: 16.20.0
NPM: 8.19.4
Info
What happened?
When you send a String (such as a JSON string with a base64 image) that's too big the connection is killed. No error or anything is created.
I am not sure how the string is "too big" maybe the download speed of the receiving peer is too slow?
What makes me think its a download speed issue?
This works fine locally, but as soon as you move to a remote client (diff device on the network, outside network etc)
The client would just disconnect.
I spent HOURS trying to figure out what the problem was, and there not being an error for "string is too big" is really stupid.
No joke, the peers would just DISCONNECT. NOTHING WAS LOGGED!
Yes, it could be argued that I should be using Streams but there should STILL be an error code OR something in the docs/readme about, "if random disconnects are happening when you use send, your string might be too big"
Maybe there is something in the readme about this but I don't know.
Please provide a minimal reproducible example that demonstrates your issue.
Take a picture and encode it as base64
Send base64 string in a string object (not required)
(Peer disconnected)
(No error)
From time to time I would get a ERR_ICE_CONNECTION_FAILURE error, however I'm unsure if this is related
code:
peer.send(JSON.stringify({img: frameObject.data// Base64 string}))// Disconnect, No Error, Nothing just disconnected.
What did you expect to happen?
The string to be sent OR for an error to be thrown
I'd also like to see a way to know how big is too big, like can I send a 5000-length string? (peer.maxString, peer.maxLength, something like that)
Are you willing to submit a pull request to fix this bug?
No, I don't know where the connection is being killed, or even how to figure out how big is too big.
The text was updated successfully, but these errors were encountered:
Keep in mind, I am still not 100% if this is the issue.
Making my base64 smaller (changing the quality of the image) fixed the issue, AKA smaller base64 string
Version Infos
What version of this package are you using?
simple-peer@9.11.1
What operating system, Node.js, and npm version?
Node: 16.20.0
NPM: 8.19.4
Info
What happened?
When you send a String (such as a JSON string with a base64 image) that's too big the connection is killed. No error or anything is created.
I am not sure how the string is "too big" maybe the download speed of the receiving peer is too slow?
What makes me think its a download speed issue?
This works fine locally, but as soon as you move to a remote client (diff device on the network, outside network etc)
The client would just disconnect.
I spent HOURS trying to figure out what the problem was, and there not being an error for "string is too big" is really stupid.
No joke, the peers would just DISCONNECT. NOTHING WAS LOGGED!
Yes, it could be argued that I should be using Streams but there should STILL be an error code OR something in the docs/readme about, "if random disconnects are happening when you use send, your string might be too big"
Maybe there is something in the readme about this but I don't know.
Please provide a minimal reproducible example that demonstrates your issue.
From time to time I would get a
ERR_ICE_CONNECTION_FAILURE
error, however I'm unsure if this is relatedcode:
What did you expect to happen?
The string to be sent OR for an error to be thrown
I'd also like to see a way to know how big is too big, like can I send a 5000-length string? (peer.maxString, peer.maxLength, something like that)
Are you willing to submit a pull request to fix this bug?
No, I don't know where the connection is being killed, or even how to figure out how big is too big.
The text was updated successfully, but these errors were encountered: