The Short Message Service (SMS), also known as "Text Messaging" is a protocol that is used by George Mason students to communicate with each other

INSTRUCTIONS TO CANDIDATES

ANSWER ALL QUESTIONS

The George Mason University Short Message Service System

Introduction:

The Short Message Service (SMS), also known as "Text Messaging" is a protocol that is used by George Mason students to communicate with each other. In fact, many students find it so convenient that they prefer to use it to "talk" to the student on the other side of the table during mealtimes rather than take the effort to actually speak to them directly.

 

Because of the amount of bandwidth being used by students texting one another, George Mason wishes to create an exclusive protocol that students will use while on campus in order to cut down on the bandwidth used over the WiFi connections. Since the Computer Science department has expertise on such protocols, the university has asked it to assist in developing a separate system for student texting.

 

Details of the SMS Protocol:

A typical SMS protocol allows 128 distinct ASCII characters to be used in a message. However, to save bandwidth, instead of using straight 8-bit ASCII characters to transfer data (one byte per character), SMS uses 7 bits per character and compacts the bits such that it only requires 140 bytes to send a 160 character message, for an approximately 12.5% savings of bandwidth.

 

12.5% savings in bandwidth is not good enough for GMU. They would like a system that can save up to 25% of the bandwidth. Therefore, a 160 character message must use only 120 bytes of bandwidth. To do this, a character set that uses only 6 bits per character must be developed. This means that the maximum number of distinct characters that can be in the "alphabet" is 64. The Department of Linguistics was consulted, and they decided that a character set that does not contain any lower case letters, but includes nearly all other printable ASCII characters could be used without major issues. Therefore, the following code and values were developed as the alphabet to be used for the GMU SMS System.

 

Table 1 - The George Mason University Standard Code for Information Interchange (GMUSCII)

 

Dec	Hex	Char	Dec	Hex	Char	Dec	Hex	Char	Dec	Hex	Char
0	00	NULL	16	10	G	32	20	W	48	30	,
1	01	.	17	11	H	33	21	X	49	31	-
2	02	/	18	12	I	34	22	Y	50	32	0
3	03	:	19	13	J	35	23	Z	51	33	1
4	04	;	20	14	K	36	24	Space	52	34	2
5	05	<	21	15	L	37	25	!	53	35	3

 

6	06	=	22	16	M	38	26       "	54	36	4
7	07	>	23	17	N	39	27       #	55	37	5
8	08	?	24	18	O	40	28       $	56	38	6
9	09	@	25	19	P	42	29       %	57	39	7
10	0A	A	26	1A	Q	42	2A       &	58	3A	8
11	0B	B	27	1B	R	43	2B       '	59	3B	9
12	0C	C	28	1C	S	44	2C       (	60	3C	[
13	0D	D	29	1D	T	45	2D       )	61	3D
14	0E	E	30	1E	U	46	2E       *	62	3E	]
15	0F	F	31	1F	V	47	2F        +	63	3F	_

 

Note: All printable ASCII characters that are NOT shown in the above table (such as a..z) will be translated to the '#' character. All non- printable ASCII characters will be translated to NULL.

 

Packing Bits:

The following system is similar to the SMS 7-bit packing system, except that it packs 6-bit characters in an array. As an example, suppose a student wishes to send the following text via the GMU SMS system:

 

CS262 IS GREAT!

 

Using the table above, each character can be given its corresponding Hexadecimal value:

 

0C 1C 34 38 34 24 12 1C 24 10 1B 0E 0A 1D 25 C   S   2   6   2                             I    S G R E A T !

 

Translating the above message into individal 8-bit bytes, we get:

00001100 00011100 00110100 00111000 00110100 00100100 00010010 00011100 00100100 00010000 00011011 00001110 00001010

00011101 00100101

 

Since we are going to only use six bits per character, we can remove the two Most Significant Bits (MSBs) with the following result: 001100 011100 110100 111000 110100 100100 010010 011100 100100 010000 011011 001110 001010 011101 100101

 

Now comes the tricky part... We will pack the bits into 8-bit bytes. These bytes will be part of our Packed Array. To do this, we start at the Least Significant Bit (LSB) of the first character. In this case, it is the letter C with the bit pattern 001100. The LSB of this pattern is the last 0 (bolded) - 001100. This bit will become the lsb of the first element in the packed array. We continue, bit by bit, until we have put the entire character in the first element of the packed array. Note that there will be two bits that are not yet initialized:

- - 0 0 1 1 0 0 <- PackedArray[0] (started)

 

Now we start on the next character, or 011100 (The letter 'S'). Starting at the LSB, we put that bit in the next available bit of PackedArray[0]: - 0 0 0 1 1 0 0, then the next LSB after that: 0 0 0 0 1 1 0 0, and we have finished the first element of PackedArray. However, we have not finished packing the letter 'S'! We still have four bits left to encode! So, those four bits will then become the least significant bits of the next element of PackedArray:

- - - - 0 1 1 1 <- PackedArray[1] (started)

 

Continuing with the third character (the character '2'), we take the four LSBs of that character, and add them to the remaining bit locations:

0 1 0 0 0 1 1 1 <- PackedArray[1] (completed)

 

However, there are two more bits left to encode from the '2' character, so they will become the LSBs of the next element of PackedArray:

- - - - - - 1 1 <- PackedArray[2] (started)

 

This continues until all of the 6-bit characters have been packed or encoded into PackedArray. Any remaining bit locations in PackedArray that are left after all the bits from the message are encoded, will be set to 0.

 

So, after the message is encoded into the packed array, the bits in the array will look like:

00001100 01000111 11100011 00110100 00101001 01110001 00100100 10110100 00111001 01001010 01010111 00000010

 

Putting these binary bytes as hexadecimal gives:

0C 47 E3 34 29 71 24 B4 39 4A 57 02

 

So, the original 15 bytes of the message have now been packed into 12 bytes, a reduction by 20%.

 

Project Specifications:

For this project, you will create a program that will pack and unpack lines of GMU-SMS text. Your program will be menu driven and contain the following options:

 

• ack and save a line of text (options are 'P' or 'p') [U]npack and print a line of text (options are 'U' or 'u') [Q]uit (options are 'Q' or 'q')

 

If the Pack and save option is chosen, you will prompt the user for two items (in this order): 1) A filename in which to save the packed array, and 2) The line of text to pack and save.

If the Unpack option is chosen, you will prompt the user for a filename which contains a saved message in the packed format. If the Quit option is chosen... Well, do whatever you think makes the most sense.

 

Detailed Specifications:

 

No unpacked message will be greater than 160 characters (including the NULL terminator).

 

When entering text from the console, the newline character must be removed from the input string. One method (of many) to do this is with the following line of code (assuming the input is contained in a char array named Buffer):

Buffer[strlen(Buffer) - 1] = '�'; /* Since the 'n' character is right before NULL terminator, make it a NULL terminator */ No packed message will be greater than 120 characters (including NULL terminator)

If the Pack option is chosen from the menu, the user will be prompted for a filename. The program will then prompt the user for a line of text.

The program will not attempt to open the file until AFTER the line of text is entered.

If the file cannot be opened, an appropriate message is displayed to the user, and the program execution will return to the menu. If the entered filename belongs to an already existing file, the existing file will be opened, and all data in the existing file will be overwritten with the new data without any prompting or warning.

If the line of text entered by the user is longer than 160 characters, the text will be truncated to 159 characters and the NULL terminator will be placed in the last element of the unpacked message array. Any characters input that are beyond this length will be discarded. (Note: You will have to handle flushing the input buffer in some manner if this occurs.)

If the Unpack option is chosen from the menu, the user will be prompted for a filename. This file will be opened and the packed char array will be read. This array will be unpacked, and the resulting unpacked cstring will be printed to the screen.

If the file cannot be opened, an appropriate message is displayed to the user, and the program execution will return to the menu.

 

All appropriate file operations (fopen()/fclose()) must be performed. Packed array data should be saved to the files using binary format.

Any printable characters entered from the console that are not part of the GMUSCII encoding will automatically be translated to the '#' character for encoding. This character will then be unencoded as the '#' character.

For example, the message "Hi There CS262!" will be encoded as "H# T#### CS262!"

Non printable characters (such as newline, escape or backspace) will be translated to the NULL character.

You may assume that any encoded file that you are given (e.g. for testing purposes) will not contain any characters that are not in the GMUSCII encoding. Any such characters will have already been translated to the # symbol before encoding.

 

Constants for array sizes (such as 160 and 120) should not be found in the body of the code. #define macros should be used. Constants necessary for bit shifting purposes (such as 6, 4 and 2) may be used directly in the code.

SMS Character Encoding:

An object file (GMUsms.o) and include file (GMUsms.h) are provided as part of this project. These files can be found in the following directory on zeus: /usr/local/shared/CS262-project. You must copy these files to your project directory using the following command on zeus:

 

cp /usr/local/shared/CS262-project/GMUsms.* .

 

Note the last period at the end of the command. Make sure you don't forget it. The GMUsms.o file contains the object code of two functions: CharToSMS() and SMSToChar(). These functions will translate characters from the ASCII character set to the GMUSCII character set and vice-versa.

 

To incorporate this file into your executable, you may use the following target in your Makefile (changing the filenames as appropriate):

 

Project2_astudent_205 : Project2_astudent_205.c GMUsms.o

gcc -o Project2_astudent_205 Project2_astudent_205.c GMUsms.o -Wall

 

You must ensure that the GMUsms.o and GMUsms.h files are found in the same directory as your project source file and Makefile.

 

You may NOT incorporate any sms translation code directly in your project's source file. In order to make your project source code "aware" of the existence of the SMS functions, you will add the following line at the top of your source file, just below the usual #include statements:

 

#include "GMUsms.h"

 

Note that there are quotation marks (") instead of the angle brackets (<>) normally found with #include directives. In a later lab, you will learn more about this. For now, just use the above method to use the GMUsms.o object file in your program. DO NOT USE THE GMUsms.o FILE IN YOUR #INCLUDE STATEMENT! Only use GMUsms.h.

 

Submission:

Create a directory according to proper naming conventions (Project2__) and copy your Makefile and source/object files (Project2__.c, GMUsms.o and GMUsms.h) to this directory. Create a tarfile of this directory (also following proper naming conventions) and submit this tarfile to Blackboard by 11:59 PM Sunday, April 5, 2020. Ensure that all files follow proper naming conventions (Note: your makefile can simply be called "Makefile"). You do not need to create or submit a typescript showing that your program compiles and runs on zeus.

 

Errata:

This section is for any clarifications or modifications to the above text as questions are asked, or errors found. The text above will be modified, and a notation will be made in this section describing the change. This is done so that proper notification can be made of these changes without undue confusion. Check this section before final submission to make sure that your program follows the most recent version of the specifications.

Related Questions

. The fundamental operations of create, read, update, and delete (CRUD) in either Python or Java

CS 340 Milestone One Guidelines and Rubric  Overview: For this assignment, you will implement the fundamental operations of create, read, update,

. Develop a program to emulate a purchase transaction at a retail store. This  program will have two classes, a LineItem class and a Transaction class

Retail Transaction Programming Project  Project Requirements:  Develop a program to emulate a purchase transaction at a retail store. This

. The following program contains five errors. Identify the errors and fix them

7COM1028   Secure Systems Programming   Referral Coursework: Secure

. Accepts the following from a user: Item Name Item Quantity Item Price Allows the user to create a file to store the sales receipt contents

Create a GUI program that:Accepts the following from a user:Item NameItem QuantityItem PriceAllows the user to create a file to store the sales receip

. The final project will encompass developing a web service using a software stack and implementing an industry-standard interface. Regardless of whether you choose to pursue application development goals as a pure developer or as a software engineer

CS 340 Final Project Guidelines and Rubric  Overview The final project will encompass developing a web service using a software stack and impleme