From what I know, all the MAC addresses that the packet gone through are in the packet. This is because that each packet that goes in a certain path, should also be returned
Actually, the MAC-address stored in the packet is changed on every hop of a packet's journey.
MAC is shorthand for Media Access Control, with media refering to the local communication media. While source and destination IP-Addresses remain the same throughout the journey (and are used for long-distance routing decisions), the source and destination MAC-Addresses just indicate the next hop.
Because of this, the MAC-Address stored in packets received by your server should be the MAC address of your point of presence-router, or of the equipment of your provider.
You might want to have a look at the OSI Layer model and encapsulation.
You have the relationship between the IP stack and the physical stack reversed. The MAC address is in the part that wraps the IP information, not the other way around. So when I send something from my computer, say, to yours, the physical segment in my LAN (Ethernet in this case) wraps around the IP stuff and includes my MAC. The router then extracts the IP information and passes that onward and upward (in this case again by Ethernet) to my DSL modem using its own MAC in the process. The DSL modem unwraps the IP stuff and sends that up the phone line using whatever protocol it uses (don't know and don't care at that point) out to ... well, you get the idea. Each physical link hop wraps and unwraps the IP information using whatever extra information the underlying physical layer involved attaches for local transmission.
You can't - unless the client is local to your server. Provided it is, you can try arp-pinging it and getting the client's mac address that way.
It's source & destination IP address which remain. The idea of inter-network is basically based on hop-to-hop delivery. Intermediate routers/host understands only MAC addresses. To my knowledge routing tables should understand machine address.
If MAC addresses could remain throughout the journey of a packet; which means there was no need of Internet Protocol addresses to be invented. And all of the internet would have used only MAC addresses :-)
You can achieve what you want only if both the server & client reside on the same local network (both hosts are connected by some L1 media).
Having said that, your application looks something like a Web Server, which tells me that it need not be on the same network.
Still if you want the MAC address of the source host at the receiving host; think to sent it as a payload?
Addition:
Networks need not be of the same type around the world (viz. Ethernet, Frame relay etc). Network layer provides us with the flexibility of routing without distinction between underlying layers(Data Link Layer) or I should say underlying L1 technology. In short, IP will give us the inter-network and Data Link Layer(where MAC addresses come into picture) will take care of communication at micro level (i.e. local network). This is a fair reason why Mac and IP addresses co-exist! :-)
In IPv6, one might actually get the computer's MAC address from the IPv6 address, if encoded into the 64 bits of the host address.
See also How to avoid exposing my MAC address when using IPv6? on Super User.
You're thinking in terms of direct connection between the server's LAN and the client's LAN, and that's just not the way the internet works. There may be any number of hops between the two LANs -- and, by the way, there is no constraint that either LAN use anything like a MAC, so "MAC addresses" are not placed in IP packets. "A MAC" makes sense only within a LAN (actulaly, only one whose lowest layers do use something like MACs;-), and are discovered/announced with the ARP and RARP protocols (which do not get routed;-).