Can .NET Remoting Make Sockets Obsolete?

Question

Hello!
I have considered .NET Remoting as an alternative to Sockets in this way:
I want clients to send files to a server
The files been transfered need to be organized ,when they reach the server.Additional metadata will accompany them.
So instead of using sockets and creating my own protocol (validate and recognize metadata/file coming together,in a appropriate form, from the socket)
i thought that .NET Remoting would make the whole process very easy.Client and Server would just exchange objects like :
class Packet(
public fileStream
public strWhoSentIt
public strTypeOfFile
....
Public FillFileStream(bytestream)
....
)
Ok!The above example was written roughly but i hope you get the idea.
What do you think about that?A bit out of the edge?
Any limitations/problems??

chrishornberger · Answer

No. Consider the whole "right tool for the job" scenario.
Take quake for instance. It uses UDP and Sockets to send map positions and health conditions, etc, to and from the server(s). Remoting wouldn't do in that case. Remoting is for when you want a well known type of object to perform a task for you. Call up a remote data fetcher and have it do all the data work on the server side then return to you a sorted, filtered, formed up data set, whereas sockets will forever have a place for things like packet-based communications, ftp, messaging systems and about a b'zillion other things, including SQL server (et al) and inter-platform communications.