Why one byte and two byte padding header is added in front of MAC PDU and more than 2 byte padding header is added in last of of MAC sub header. Instead of that they can keep padding in last sub header, what is the reason behind that.
In case of single byte or two byte padding , If you add sub header in last then you need to mention length field in the before sub header , but you have only one or two byte extra then if you add length field in the last one byte will be extra needed. that is the reason padding is done in the end.
Say example MAC is having 101 byte of grant and RLC data is one PDU which is of 99 byte and MAC header is needed 1 byte because only one PDU so one byte is enough. follow below first image,padding is needed for 1 more byte (99(Data) + 1 (SDU header)+ 1 (padding)). If i add padding in the end then (see second image) it will become 101 byte but if i add in the beginning(see image 3) it will be sufficient. For Padding sub header no need to mention length even if it is not a last sub header ,implicitly receiver MAC knows it.
So this is the reason one or two byte padding is done in the beginning.
Pictorial view click here
Related
So I tried implementing the MD5 algorithm according to RFC1321 in C# and it works, but there is one thing about the way the padding is performed that I don't understand, here's an example:
If I want to hash the string "1" (without the quotation marks) this results in the following bit representation: 10001100
The next step is appending a single "1"-Bit, represented by 00000001 (big endian), which is followed by "0"-Bits, followed by a 64-bit representation of the length of the original message (low-order word first).
Since the length of the original message is 8 (Bits) I expected 00000000000000000000000000001000 00000000000000000000000000000000 to be appended (low-order word first). However this does not result in the correct hash value, but appending 00010000000000000000000000000000 00000000000000000000000000000000 does.
This looks as if suddenly the little-endian format is being used, but that does not really seem to make any sense at all, so I guess there must be something else that I am missing?
Yes, for md5 you have to add message length in little-endian.
So, message representation for "1" -> 49 -> 00110001, followed by single bit and zeroes. And after add message length in reversed order of bytes (the least significant byte first).
You could also check permutations step by step on this site: https://cse.unl.edu/~ssamal/crypto/genhash.php.
Or there: https://github.com/MrBlackk/md5_sha256-512_debugger
When I see the DHCP RFC at http://www.ietf.org/rfc/rfc2131.txt , it says that lease time and server identifier fields come under options. Which bits in the DHCP packet actually represent these field?
It's not possible to give you a specific byte offset to look at - you have to interpet the "Options" section of the packet. The Options can be given in any order.
Take a look at the definitions of the Options here: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_options
Options are variable length octet strings. The first octet is the
option code, the second octet is the number of following octets and
the remaining octets are code dependent.
So if you have DHCPOFFER packet to decode, you need to start at the beginning of the Options section (octet offset 812 into the entire DHCPOFFER packet), and interpret each Option (code, length, data) until you reach the end of the packet. Then look at which Option had a code of 51 (lease time) followed by a length octet of value 4 and then 4 octets of data, or 54 (Server identifier) again followed by length 4 and 4 octets of data.
TCP client sends data byte by byte. So, how to tell the server that this message has ended and the new message begins now?
One way is to fix a special character that'll be sent as a bookmark, but that character can also be a part of the message causing confusions.
Any other optimum way out?
If the message is binary, delimited encoding using a special character is not possible. Tag Length Value (TLV) encoding will be best suited for this.
for example
+--------+----------+----------------+
| Tag | Length | Content |
| 0x0001 | 0x000C | "HELLO, WORLD" |
+--------+----------+----------------+
in addition to that, you can have more than one message type
One possible way can be that before sending the actual message you can send the number of bytes in the particular message. When the receiving side has received that number of bytes it can start receiving next message
Checkout the implementation used in networkComms.net, the open source communication framework. In particular IncomingPacketHandleHandOff() on line 892 here.
It guarantees that the first byte received specifies the size of a packet header (Less than 255 bytes). Once enough bytes have been received in order to rebuild the header, the header can be inspected to determine remaining size to be received (data section). If you have more incoming bytes than the expected header and data sections you look at the very first byte and start over.
Using bookmarked characters is what is used at the base level of the network stack but must be implemented carefully to avoid further complications.
If you wish to use a character as both the end of message marker or as a part of the message, you need to use an escape sequence.
For example: Use the character '$' to end the message, and '%' to escape
i.e.
%$ -> $
%% -> %
then use '$' to end the message
All alternatively send the number of bytes to be received at the start of the messssage (or message chunk if you do not know the lenght of the complete message at that point).
Please let me know the maximum number of "Album Name".
Now I'm developing Photo Upload app with Graph API.
When creating an album, the album name gets corrupted if the number of Japanese characters exceeds 21.
Below is the example of this issue.
e.g.
Input:
あいうえおかきくけこあいうえおかきくけこあい
Registered Album Name:
あいうえおかきくけこあいうえおかきくけこあ��
Note that the same issue occurs if more than 21 Korean or Chinese characters are set as Album Name.
It would appear that there is a length limit on this field. Guessing that they're using UTF-8, it would be a limit of 64 bytes, rather than a integral number of characters.
Facebook appear to be truncating the string at that number of bytes, regardless of whether that byte limit happens to align with a character boundary or not. This kind of misbehaviour is unfortunately common in languages that don't handle text strings as Unicode characters natively. In your case the last い takes up three bytes, but there's only room for two, so you get left with two trailing bytes that don't form a valid UTF-8 sequence, hence ��.
To stop this happening you'd have to do their job for them and impose the length limit in a Unicode-clean way. One way to do this would be to encode to UTF-8 yourself, do the truncation, and convert back to characters ignoring the invalid end bytes. eg in Python:
>>> print u'あいうえおかきくけこあいうえおかきくけこあい'.encode('utf-8')[:64].decode('utf-8', 'ignore')
あいうえおかきくけこあいうえおかきくけこあ
I wanna know how the onMetaData marker in FLV files looks like. When i open FLV files as plain text I get this:
FLV[][][][][](TAB)[][][][][][][]8[][][][][][][][][]
onMetaData[]
duration...
The docs say the first 3 bytes are the signature "FLV" the next byte tells the flv version, the next byte is telling us if audio or video tags are present, the next 4 bytes are the data-offset(the size of the header), which is 9, in ascii its the TAB code. after the TAB starts the body with the fist "previous tag size field" which is 0(4 bytes) next, there is the Tag Type (1 byte) the data size (3 bytes) and the timestamp (4 bytes) the stream id (always 0, 3bytes). After that remains:
[]
onMetaData[]
[][][][][][]
duration...
I suppose the onMetaData marker is "1byte, newline"onMetaData"1byte,newline) but what are the 7 bytes between onMetaData marker and duration?
You would need to view this file in a hex editor to get anything useful from it; a text editor will just show you unprintable characters.
The ASCII "onMetaData" bit in the file is the tag header, which is wrapping the "duration" field. The three bytes immediately after "onMetaData" are the BodyLength of the tag (uint24, big-endian), and the next 4 bytes ("\x00\x00\x00\x08") describe the length of the name for the next tag, which is "duration."
I suggest you to use hexedit tool http://www.hexedit.com/
this will allow you to see all the info in string format..
as well as it has very nice navigation to analyze bytes.
In addition to it, use https://www.adobe.com/content/dam/Adobe/en/devnet/flv/pdfs/video_file_format_spec_v10.pdf to get details about all bytes in an flv file
Remember that the metadata is encoded using AMF. This means that after the string "onMetaData" you have a 0x08 to signify the start of an array and then 2 bytes to signify the length of the first element as number of character/bytes