If I am using a block cipher such as AES which has a block size of 128 bits, what do I do if my data is not an even multiple of 128 bits? I am working with packets of data and do not want to change the size of my packet when encrypting it, yet my data is not an even multiple of 128?
Does the AES block cipher allow handling of a final block that is short without changing the size of my message once encrypted?
The algorithm itself demand that each block will be 128 bit, but actually it depends on particular implementation. But what is keeping you from padding your data with zeroes to make it multiple of 128 if that is a requirement and not supported automatically by implementation?
With a block cipher you need to specify the length of the message being sent because of this fact, then just fill the unused part of the last block with random data. You should probably be using a cipher mode. Not to mention HMAC or some sort of integrity system, depending on what you are using AES for.
AES simply says how to encrypt 16 bytes of data into a block and nothing else.
It's really an implementation detail. While the algorithm will require a complete block, your implementation will probably pad the final block with zeros or random data.
That kind of detail depends on the chaining mode which you use. The chaining mode is what defines how many times you invoke the AES primitive. and on what, for a given input message. The simplest chaining mode consists in simply splitting the input data into successive 16-byte blocks and encrypting each of them independently; this is called ECB (as "Electronic Code Book") and it is known to have weaknesses (namely, if two input blocks are identical, something which is frequent in "real life" data, then the two corresponding output blocks will be equal to each other as well, and anybody can see that).
Some chaining modes enlarge the data, i.e. the encrypted message will be slightly larger than the input message. Other chaining modes (e.g. CTR) do not. Almost all secure chaining modes require handling an "initial value", which is a piece of data (usually the same size than a block) which needs not be secret, but must be known to both the sender and the receiver, and must be distinct for each message. Some modes (e.g. CBC) require a uniformly random IV, whereas some other modes will be happy with a simple counter. It is customary to send the IV along with the encrypted message. You could also derive the IV from the secret key itself with a hash function.
These things are tricky, and it is difficult to know whether you did it right: security cannot be tested; a weak cryptosystem compiles and runs just like any other application. Designing your own cryptographic protocol is not recommended. At all. Employing robust primitives is no guarantee that the result will be secure.