Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a Message class #5

Closed
fabiodrg opened this issue Apr 6, 2019 · 1 comment
Closed

Implement a Message class #5

fabiodrg opened this issue Apr 6, 2019 · 1 comment
Assignees
Labels

Comments

@fabiodrg
Copy link
Collaborator

fabiodrg commented Apr 6, 2019

Maybe makes some sense to have another class to generate and parse Messages. Since the communication for control messages is UDP, this class could be able to receive DatagramPackets and generate DatagramPackets according to the subprotocol being used.

Generic format

All messages have the following header: <Message type> <Version> <SenderId> <FileId> <ChunkNo> <ReplicationDeg> <CRLF>

  • Not all control messages have all fields, but appear in the relative order as illustrated above.
  • Moreover, all fields are separated between one or more spaces.
  • The header always terminates with the sequence <CRLF>, in addition to the <CRLF> shown above. Might have spaces in between, but no other charcaters.
  • Strings in Java are UTF-16! The fields must be ASCII characters, therefore each character should take a single byte!

Common fields

Every message has:

  • MessageType
  • Version
  • SenderId

Other fields must are specific to sub-protocols, which could extend this Message class, however, might not be worth it.

Utility methods

Some fields have specific encodings, thus this class should offer protected methods to handle it.

Tip: String class offers the method getBytes, which allows to specify the encoding. Also see StandardCharsets

  • MessageType: Just the type of message. A sequence of ASCII characters. Variable length.
  • Version: Three ASCII characters in format <n>.<m>, where n and m are ASCII digits.
  • SenderId: Variable length of the sender ID.
  • FileId: The file SHA256 hash. This hash takes 32 bytes, however, this field should take 64 bytes! Each byte of the hash is encoded as two ASCII characters. For instance, a byte 0xB2 from the hash should be encoded as B2 in the field. Handle both uppercase or lowercase characters, i.e, B is the same as b. Represented in big-endian order.
  • ChunkNo: The chunk number, which is an integer, should be encoded as a sequence of ASCII characters for each digit. I.e., the number 123 is encoded with the ASCII characters that represent 1, 2, ..., starting at most significant digit. Can't be larger than 6 chars, therefore maximum file size is 64GB.
  • ReplicationDeg: Single byte. ASCII character for the digit (which means replication degree ranges from 0 to 9).
@fabiodrg fabiodrg self-assigned this Apr 6, 2019
@fabiodrg fabiodrg added the High Priority label Apr 6, 2019
fabiodrg added a commit that referenced this issue Apr 6, 2019
@fabiodrg
Copy link
Collaborator Author

fabiodrg commented Apr 6, 2019

I am going to create a new class for each sub-protocol. Maybe not the best approach, but it's a way to start. More common functionality between sub-protocols goes to Message. The later is going to be Abstract from now on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant