Reply to thread

Message

The way I see it, if you want quick turn around time on the development front (and you have and IIS-enabled server) you're safest bet is WS on .Net 2.0.

With a bit more time (learning curve), WCF on .Net 3.0 sounds like the perfect candidate for the TV Server side of things, because as it was said it can be made to use standard WS upstream, so as far as the client is concerned, it's talking to a standard Web Service.

Now, creating a simple communications protocol talking over TCP is definitely a simple approach which will be cross-platform as long as the protocol is well defined. The main issue I see with this, is that you have to do this from scratch and you have to ensure a multi-client, multi-connection paradigm is implemented. This is precisely what the 2 options above have already done for you after thousands of hours of testing, so arguably the stability is also an advantage of these.

I have written this sort of software before (heavy duty SFTP server code) and as long as you're confident in your multi-threading skills, this can be achieved in a relatively straight forward (but not quick) manner. It's just that testing/debugging can be a serious hindrance in this sort of scenario that Microsoft has already done for you in WS and WCF

One thing I believe we're (most if not) all agreed on is that Remoting should be put away for good, as this is a technology that MS wants to forget (and I know this first hand). perhaps Frodo can tell us why this was the technology of choice? I guess cross-platform compatibility wasn't on the agenda when the original design was done.

My £0.02 of input.

AL

<blockquote data-quote="drfonz" data-source="post: 125968" data-attributes="member: 26014">The way I see it, if you want quick turn around time on the development front (and you have and IIS-enabled server) you're safest bet is WS on .Net 2.0. With a bit more time (learning curve), WCF on .Net 3.0 sounds like the perfect candidate for the TV Server side of things, because as it was said it can be made to use standard WS upstream, so as far as the client is concerned, it's talking to a standard Web Service.Now, creating a simple communications protocol talking over TCP is definitely a simple approach which will be cross-platform as long as the protocol is well defined. The main issue I see with this, is that you have to do this from scratch and you have to ensure a multi-client, multi-connection paradigm is implemented. This is precisely what the 2 options above have already done for you after thousands of hours of testing, so arguably the stability is also an advantage of these.I have written this sort of software before (heavy duty SFTP server code) and as long as you're confident in your multi-threading skills, this can be achieved in a relatively straight forward (but not quick) manner. It's just that testing/debugging can be a serious hindrance in this sort of scenario that Microsoft has already done for you in WS and WCF <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />One thing I believe we're (most if not) all agreed on is that Remoting should be put away for good, as this is a technology that MS wants to forget (and I know this first hand). perhaps Frodo can tell us why this was the technology of choice? I guess cross-platform compatibility wasn't on the agenda when the original design was done.My £0.02 of input.AL</blockquote>

[QUOTE="drfonz, post: 125968, member: 26014"] The way I see it, if you want quick turn around time on the development front (and you have and IIS-enabled server) you're safest bet is WS on .Net 2.0. With a bit more time (learning curve), WCF on .Net 3.0 sounds like the perfect candidate for the TV Server side of things, because as it was said it can be made to use standard WS upstream, so as far as the client is concerned, it's talking to a standard Web Service. Now, creating a simple communications protocol talking over TCP is definitely a simple approach which will be cross-platform as long as the protocol is well defined. The main issue I see with this, is that you have to do this from scratch and you have to ensure a multi-client, multi-connection paradigm is implemented. This is precisely what the 2 options above have already done for you after thousands of hours of testing, so arguably the stability is also an advantage of these. I have written this sort of software before (heavy duty SFTP server code) and as long as you're confident in your multi-threading skills, this can be achieved in a relatively straight forward (but not quick) manner. It's just that testing/debugging can be a serious hindrance in this sort of scenario that Microsoft has already done for you in WS and WCF :) One thing I believe we're (most if not) all agreed on is that Remoting should be put away for good, as this is a technology that MS wants to forget (and I know this first hand). perhaps Frodo can tell us why this was the technology of choice? I guess cross-platform compatibility wasn't on the agenda when the original design was done. My £0.02 of input. AL [/QUOTE]