I got this error after sending message via webrtc, the message contents file image.
Message too large (can send a maximum of 262144 bytes)
How can I achieve this one. Thanks in advance.
Cheers
This is done by splitting the file into several chunks and then reassembling on the other end. https://webrtc.github.io/samples/src/content/datachannel/filetransfer/ shows how.
Related
I am currently working on an application to change my RGBWW light strips by a Java application.
Information has to be sent via UDP packages in order to be understood by the controller.
Unfortunately, the hex number 0x80 has to be sent - which is causing some problems.
Whenever I send a byte array containing only numbers fron 0x00 to 0x79 (using DataPacket and a DataSocket), I do get an UDP Package popping up on my network monitor.
As soon as I include the number 0x80 or any other higher, I see two things Happen:
1: I do not longer get only UDP protocols, but messages are displayed as RTP / RTCP most of the time
2: The method Integer.hexToString() does not display "80", but gives me a "ffffff80".
My question: Is there something I am missing when it comes to sending hex info by UDP? Or is there another way of sending it, possibly avoiding the annoyingly signed bytes?
I unfortunately did not find any information that would have significantly helped me on that issue, but I hope you can help me!
Thanks in advance!
I was sending .5 mb size dictionary through iPhone to watch os2, however every time it is giving message reply failed. It is working correctly in watchos1. There are 700 objects in that dictionary.
Please help.
The payload size is dependent on how you send the content from the phone to the watch. You may want to consider breaking your dictionary into smaller chunks, (smaller than 65KB), or write the dictionary to a file you can then send using WCSession's transferFile:metadata method.
For more info, see this question and answer, and take a look at the docs for WCSession. The file size limits aren't documented, and may change in the future.
My andriod app is bandwidh constraint. It should work in as low as 64kbps net.
The user will record voice (max length 120 sec, avrage 60 sec)
and then will encode it with encoder (options are:
1. Losless: FLAC or ALAC?
2. lossy: MP3?
Say file is 1024 kb i.e. 1 MB.
So I am thinking sending file by dividing into of chunks of size 32kb
and
if response is received in 1 sec after request:
exponentially increasing size of chunks then
else
The app will binary search for exact chunk size.
3. Is my approach to transfer an audio from android to server
feasible for low speed connections?
4. Or is it better to push the entire file in
multi-part form-data to server in one https post call?
Assuming you are doing this:
Record an audio file
Compress file
Upload file
You are uploading over https which uses tcp. There is no reason to exponentially increase the size of chunk because internally TCP does this automatically to fairly share bandwidth. It is called Slow Start.
No reason to chunk up in to pieces and let it grow. Additionally, the max packet size is 64k.
Just open a stream and send it. Let the underlying network protocols take care of the details.
On your server, you probably have to change server settings to allow large file uploads and increase the timeout settings.
I'm evaluating using NSQ, http://nsq.io/, for a specific project. The idea is to setup a data pipeline where each step is a job, and where the state ideally will be located in the message body.
Which got me to think about a potential maximal message size. I don't manage to find any documentation on the subject. Can it be any size? I guess it will affect performance if messages are big enough to not fit in memory.
As Aldo mentioned, the default maximum message size is around 1 megabyte.
This is easy enough to change with the max-msg-size switch for the NSQ daemon. Here is an example of how to use it:
nsqd --lookupd-tcp-address=127.0.0.1:4160 -max-msg-size=2097152
This tells the NSQ daemon (nsqd) that max message size should be 2 megabytes instead of the default.
Using this setting, you could indeed have a message that would fill up your memory, as you mentioned in a comment.
as far as I can tell from the documentation, it looks like it's 1MB by default.
I know it sounds like a lot but I managed to hit this limit.
What I'm doing now is to send an NSQ message with the minimum amount of data regarding the event, and get the full data on the other end when I handle it.
If a user requests a large file from an Apache web server, but cancels the download before it completes, is this logged by Apache?
Can I tell from the log file which responses were not sent fully, and how many bytes were sent?
Yes, it logs those requests, but you need to use mod_logio to know the actual bytes sent, else it will show the total amount of bytes of the file. And to know which have failed you'd have to either:
use the %X format modifier and use a custom log format
compare the actual bytes sent against the files' sizes (why would you if you have the first option :-) )
Yes. If I remember correctly, it will show the amount of bytes transferred before the download was interrupted. You could then work out how many bytes should have been sent for that request and compare.
If you're using PHP (as the question was tagged a minute ago), you could probably do some sort of response buffer, where you chunk out the file in smaller bits. Start off by working out how many chunks you need to send, write a log (to db, or the syslog) to say you've started and once you hit the final chunk, another to say you've finished (or delete the first).