I'm going to digest your entire post little by little...
Let us say a Slave or Master is sending multiple bytes to the receiver
on I2C bus and the number of bytes is not defined before hand.
But it should be defined. If random information was being sent or received, you'll never be able to interpret it.
So then how will the sender tell the receiver that it has no more data
The manufacturer determines how many bits it needs to receive from the slave. The master is typically written by some logic device like a microcontroller, CPU, etc.
So far what I understand is that for the case when the sender is
Master then it sends a NACK to tell the Slave (Receiver) that there is
no more data to send.
No, not entirely right correct. A "NACK" occurs when the master doesn't "hear" anything back from the slave after it sends this bit to the slave. It's like being on the phone and saying, "Hello, are you there?"
But I wonder how does this handshaking takes place between a Master
and Slave when the Slave is sender and the Master is receiver and only
the Slave (sender) knows when there is no more data to send to the
Your definition of sender and receiver is skewed. Both the master and slave act as both a sender and receiver. The master can both send and receive, depending on write or read operations respectively.
Helpful advice: Consider reading any I2C slave datasheet. Look for the keyword, "message". This is the information that the master sends to the slave.
Picture from here... not my picture.
The master should be programmed to read the same length of the address frame as the slave, which is defined by the datasheet of the slave. You also may be able to set an address of a slave but usually not by much. This will help addressing conflict if two slaves share the same address.
Here's an example of a part that I actually just recently worked with, it's an ADM1276 hot-swap controller. It abides by the PMBUS specifications but the I2C topology still applies. It tells you the interactions of master and slave when you're sending, receiving, reading, and writing bytes.