I am using IoT Foundation on Bluemix and trying to send a byte array representing a simple text file, whose size is only 1354 bytes. I do not see anything arriving on IoT Foundation, it looks like I am hitting the 4KB payload limit (IoT Foundation doc). The shortest byte array I am able to send is only 1349 bytes. Is this a limitation of current IoT Foundation implementation?
there is a payload limit of 4096 bytes. If you attempt to send a message with a payload greater than this, the connection will simply be terminated.
If you are sending JSON, don't forget that the JSON syntax is included (including pretty printing) in the payload size. With a pure binary payload you will be able to send a payload of exactly 4096, but you will have to calculate the size in bytes of any string (after encoding) that you send.
Please can you double check how large the payload is and confirm it really is less than 4096 bytes ?
thanks
Paul
Related
I am writing my own CANOpen stack, and I want to implement the SDO server using C.
The CiA CANOpen Application Layer Document specified that the SDO Request and Confirm Frames look as follows:
And some explanation provided as follows:
Based on my decoding of this picture, I gather that I am supposed to send 8 bytes in a SDO confirmation frame, but the 7 bytes will contain simply 0.
Is this correct?
PS: Sorry for the images if they are not clear.
Almost correct. An SDO CAN frame always contains 8 bytes, where the unused bytes are 0.
The confirmation frame, however, has 4 non-zero bytes. The first byte is the command specifier (0x60 in this case). The next three are the "multiplexer": two bytes for the object index (little-endian) and one byte for the sub-index.
From Google File System paper, Application communicates with GFS Client by sending (filename, byteRange) and then GFS Client converts that byteRange to ChunckIndex. From the document it is unclear to me
Does byteRange represent begin and end of bytes to read/write OR does it represent number of bytes to read/write?
How does GFS Client convert byteRage to ChunkIndex? What is the formula behind it and what other variable(s) beside byteRange involved in this calculation?
Thank you,
byte range vs byte offset: the client translates byte offset NOT byte range to chunk index. byte range is used later when client sends read request to chunk server.
translate byte offset to chunk index is simple: because chunk size is fixed at 64MB. say the client wants byte offset at 65MB, then the chunk index would be 1. and if client wants byte offset at 130MB, then the chunk index would be 2.
I am reading slim 3 docs and found that it does read/send the response body text in chunks of 4096 bytes:
responseChunkSize Size of each chunk read from the Response body when
sending to the browser. (Default: 4096)
What is the point of doing it so? Wouldn't it better to send the response body at once? Would this imply a small overhead?
During sending response to client browser, content length of response body may or may not be available.
In both cases, responseChunkSize settings is used as number of bytes to read from body until it reaches end of file. If content length is known and it is less or equal than responseChunkSize, then it only takes one iteration to read body's content.
By reading and output response in smaller chunk, browser does not wait too long to get first byte. Reading big chunk is slower and may require larger memory consumption so browser will likely get first byte longer than smaller chunk.
Assume I have defined my own application layer protocol on top of TCP for Instant Messaging. I have used a packet structure for the messages. As I am using symmetric (AES) and asymmetric (RSA) encryption, I obtain a different
packet size for different message types. Now to my questions.
How to read from a socket that I receive a single application layer packet?
What size should I specify?
Thanks in advance.
I have two approaches in mind.
Read from the TCP stream a fixed amount of bytes that represents the
actual packet size, and finally re-read from the stream the former gathered size of bytes.
Read the maximal packet size from the stream. Verify the actual size of
obtained bytes and decide so which message type it was.
Now, a more general question. Should I provide metadata like the packet size, encryption method, receiver, sender, etc.? If yes, should I encrypt these meta data as well?
Remember that with TCP, when reading from the network, there is no guarantee about the number of bytes received at that point in time. That is, a client might send a full packet in its write(), but that does not mean that your read() will receive the same number of bytes. Thus your code will always need to read some number of bytes from the network, then verify (based on the accumulated data) that you have received the necessary number of bytes, and then you can verify the packet (type, contents, etc) from there.
Some applications use state machine encoders/decoders and fixed size buffers for reading/writing their network data; other applications dynamically allocate buffers large enough for the "full packet", then continue reading bytes from the network until the "full packet" buffer is full. Which approach you take depends on your application. Thus the size you use for reading is not as important as how your code ensures that it has received a full packet.
As for whether you should encrypt additional metadata, that depends very much on your threat model (i.e. what threats your protocol wants to guard against, what assurances your protocol needs to provide to its clients/users). There's no easy way to answer that question without more context/details.
Hope this helps!
I used a ts analyzer for a .ts file i have with mpeg-2 codec and i found out that it splits in 7311 packets.
I m trying to find this through matlab by using fopen to open the ts file in binary and fread to read the file but all i get is a column with a huge collection of numbers(way above the number of packets). Does anyone know how can i determine which of these data are the packets? Or if someone knows another way to find the packets would help me a lot.
Thank you in advance
From some quick googling, the MPEG-2 transport stream ('ts') format consists of packets 188-bytes in length, each having a 4-byte header followed by a 184-byte payload. Essentially, you can count the number of packets by counting the number of headers you find - but beware that, if you are only interested in counting the number of, e.g., video packets in the stream, then you will need some deeper analysis of the headers, because the stream may contain any number of interleaved "elementary streams" (which can be video, audio, or arbitrary data). Each elementary packet type in the stream is denoted by a unique "PID" which is contained in the header.
Aside from the above, you will also have to handle synchronisation - each header begins with the "synchronisation byte", which has a value 0x47 (or 01000111 in binary). According to this resource, decoders begin by looking for this synchronisation byte; once they find one, they may have found a packet header. To make sure, they try to find three consecutive synchronisation bytes (188 bytes apart in the stream); if three are found, synchronisation can occur and the packet boundaries may from then on be assumed at 188-byte intervals. Note, however, that the first byte of each assumed header should be checked to see if it is a synchronisation byte - if it is not, then this is called "sync loss" and the syncrhonisation process must start again.
Once you have some code to syncrhonise to a stream, it should be fairly easy to extract the PIDs from the header of each packet and count the number of packets associated with each unique PID you find. You should probably also check the first bit after the synchronisation byte as, if set to 1, this indicates a transport error, and the packet's payload is invalid. Detailed information on the format of packet headers can be found here.