The subject "Choosing a channel" from the framework documentation might be of help: ms-help://MS.NETFrameworkSDK/cpguidenf/html/cpconchoosingchannel.htm
If the URL doesn''t work, you can find it under Programming with the .NET Framework->Accessing objects in other Application Domains using .NET Remoting->.NET Remoting overview->Channels->Choosing a channel. In fact, I suggest you read all of that section.

---

For those who believe in God, most of the big questions are answered. But for those of us who can''t readily accept the God formula, the big answers don''t remain stone- written. We adjust to new conditions and discoveries. We are pliable. Love need not be a command or faith a dictum. I am my own God. We are here to unlearn the teachings of the church, state, and our educational system. We are here to drink beer. We are here to kill war. We are here to laugh at the odds and live our lives so well that Death will tremble to take us -- Charles Bukowski

I looked through the MSDN and found what I was looking for. I can''t believe I skipped over that stuff, I guess thats what happens when you skim heh. Thanks for pointing me in the right direction(or should i say making me double-check).

Now that I''ve settled on a channel type and whatnot...

How about giving me some reasons why NOT to use .NET Remoting. Obviously microsoft gives us plenty of good reasons too...but I''m looking to get some info from someone who is a neutral party.

What are the pro''s and con''s of .NET Remoting as a whole?

Thanks again guys,
Synth0id

You''re going to be sending a lot of extra information that will slow your game down. The price of a general-purpose solution is generally performance in specific situations. For a large, complex game like a MMOG that can be fatal.

agreed. using someone else''s stuff is gonna give you a whole lot of overhead that you don''t need.


Find me one that tells you how to program a MMOG net engine and I will gladly pick it up.


you''re not gonna find the book "How to Program a MMOG", but you will find plenty of books on winsock and other networking api''s like it. i''d recommend those. the part of the programmer (you) is to take networking knowledge and apply it to the MMOG idea.

M@ the MadProgrammer

quote:

---

Original post by Synth0id
What are the pro''s and con''s of .NET Remoting as a whole?

---

You don''t want to know the pros and cons "as a whole". .NET Remoting was designed for a purpose, and that purpose is to allow for communication between components that is independant of the physical location of those components. It was not designed as a high-performance communication protocol for client-server applications. You need to use the right tool for the job, and .NET Remoting is not really the right tool for an MMO games communication system.

On the other hand, if you''re not expecting large numbers of players (say, less than 30) and each player doesn''t require a lot of bandwidth (say, a couple of updates per second), then perhaps Remoting will work. Just remember that you''re not using your resources in the most efficient way possible.

If I had my way, I''d have all of you shot!

---

codeka.com - Just click it.

Well I wasn't planning on sharing every players object with ever server. That'd be overkill and certainly would suck up huge amounts of bandwidth and processing. I was thinking about using it for specific objects that would best be shared by different servers.

One of the major reason's I've settled on .NET Remoting is because of the fact that I don't want to be sitting here programming the network side for years. I want to do this, then move onto other parts and if I need to hurt performance a bit then so be it. I don't want to use something that would suck for this kind of thing though, and if .NET Remoting is a crappy way of sharing objects then I won't use it. If this is indeed the case I would appreciate people sharing some alternatives. And keep in mind that I don't want to create my own object sharing engine becuase that in itself is a huge endeavor, I mean why reinvent the wheel.

EDIT: @MadProgrammer - I was being sarcastic about that MMOG book

Also I am somewhat familiar with programming in Winsock, but again I have a schedule I'd like to keep and building an engine from scratch, using Winsock, wouldn't really cut it.

Lastly, I'm using .NET Remoting in conjunction with a DirectPlay9 front-end. Feel free to rip into that idea as well lol

Thanks again,
Synth0id

[edited by - Synth0id on December 1, 2002 3:46:32 AM]

I don''t understand why you would need object sharing for a MMOG?.. If you are somewhat familiar with winsock it shouldn''t take you that long to implement a packet_send() and a packet_receive() function (or packet class :-).. on top of this you will have to create a protocol. No matter what you''re going to use you will still have to define a protocol for your game.. and that is a lot harder than the network send/receive etc code, in my opinion :-)

Synth0id,

If you choose TCP for your Remoting channel protocol, you should also look at using the Binary Formatter instead of the SOAP formatter. The Binary Formatter is quite a bit more efficient than the SOAP formatter. The only problem is that the Binary Formatter limits your clients to using .NET only.

If someone was to write a UDP channel and custom binary formatter, .NET Remoting could be used for games, no problem. A few custom attributes here or there (to mark methods as needing to be reliable etc) and you''re all set. Now, granted, this is no simple task but it is far from being impossible.

Still, a pure sockets-based approach should always be faster than anything you could come up with in .NET Remoting.

Good luck and have fun!

winsock might require a few more calls to initialize, i dont see how that''d throw off a timetable that much...
but then again, you were thinking HTTP was possibly a viable option for a MMORPG.

I think a few of you are thinking that I would be using the Remoting for client to server communication as well, which is not the case. I would only be sharing objects between servers as there would be more than one and they would quite possibly need to share information in an efficient way.

@previous post Anonymous Poster and DigitalFiend

I was considering my options with the HTTP protocol because I was going to be specifically using the binary formatter no matter which i used HTTP or TCP. I was thinking that since I would only be using the core features of HTTP that it would basically be making use of TCP within the HTTP only and no extra shtuff, hence a very similar speed to straight TCP. Perhaps there was some extra features that HTTP would provide me that I might have found usefull but it seems everyone is pretty much totally against it so i''ll move on.

For the server to client communication I will be using DirectPlay 9.0 and its Unguaranteed packet feature(i.e. UDP i think) which will provide me with plenty of stability and already built in player management. Overall an easier platform to start on than straight Winsock, from which i''d have to make everything from scratch(again...i want to be able to finish this within my lifetime hehe).

I''d like to hear more on peoples opinions, and any more suggestions would be great as well

Thanks,
Synth0id