I was browsing around for programming troubleshooters, and I was wondering what the alternate would be for Socket Programming; if there is one.
-
Assuming you have control over the protocol being used, you could go for a higher level of abstraction like .NET's Remoting or WCF.
jro : Don't waste your time with Remoting. It's being deprecated.Cody Brocious : jro, Mono's WCF support is limited, so Remoting is the only choice if you care about Mono. -
TCPClient and UDPClient abstract you from the underlying sockets to some degree. They're nice to work with.
-
There are a ton of communication methods and protocols depending on the communication environment and scenarios. Socket programming is great for high-performant, intranet communication. The downside is that you have to supply your own protocol and message structure since communication is binary. This isn't a very interoperable solution if that is what you are striving for. There is IPC (for process-to-process named pipes). For internet communications, you can use legacy ASMX web services, MSMQ (message queueing), or the newer WS-protocols.
I recommend looking at WCF which is an SDK that unifies many of these communication technologies. WCF abstracts your business logic from the underlying plumbing. A single service can support binding to various transport technologies by only changing metadata while the underlying WCF framework handles the rest (this is over simplifying a little but it gets the point across).
0 comments:
Post a Comment