[Development] Burning Skies: Profaned Sanctuary

I think I get it. You all aren't concerned about having a GUI, you all are concerned that I don't know how to implement a GUI successfully. If the server was lagging, it wouldn't be the GUI's fault. That's not only because it's rare that the draw method is called, I dedicate a thread to the GUI. When I want to write a line to the "console", I invoke the thread. I tell the textbox holding the console lines to begin writing the line: "_outputTextBox.BeginInvoke(_writer, line);" It will never block the server. The COM threading model of the server is MTA. It's defined as an attribute on the main function. The server's thread is of the highest priority, while the GUI thread is not. The performance loss of having the GUI is so insignificant. The benefits of having the GUI and the ability for me to show my server in action to my professors in a clean way, outweigh the insignificant costs of running it.

Quote:

Originally Posted by Fаng I think I get it. You all aren't concerned about having a GUI, you all are concerned that I don't know how to implement a GUI successfully. If the server was lagging, it wouldn't be the GUI's fault. That's not only because it's rare that the draw method is called, I dedicate a thread to the GUI. When I want to write a line to the "console", I invoke the thread. I tell the textbox holding the console lines to begin writing the line: "_outputTextBox.BeginInvoke(_writer, line);" It will never block the server. The COM threading model of the server is MTA. It's defined as an attribute on the main function. The server's thread is of the highest priority, while the GUI thread is not. The performance loss of having the GUI is so insignificant. The benefits of having the GUI and the ability for me to show my server in action to my professors in a clean way, outweigh the insignificant costs of running it.

[MTAThread] won't work for some controls. Plus, a GUI is useless for a server. Only commands are required. If you want a GUI, fine, but I would say, put all your output in the normal console. Not a fake one that requires much more for nothing. By building your application as a console app, you'll get both the GUI and a console.

Else, most services (httpd, mysql, etc) are process without any GUI. There is a reason :rolleyes:

Anyway, I understand the interest of having a GUI, but please, don't output everything in your fake console, use a real one. Plus, don't use MTAThread with WinForms. Microsoft doesn't support MTAThread with WinForms, so it's unsafe to use it. Just try some dialog, you'll see that the app will crash.

Quote:

Windows Forms is not supported within a MTA or free threaded apartment. Applications using Windows Forms should always declare the apartment style they're using, as some other component could initialize the apartment state of thread improperly.

[Only registered and activated users can see links. Click Here To Register...]

I safely run the server in MTA. The thread I run the GUI in is STA. I know how to implement a GUI and I know about these performance losses. They're insignificant though. Enough.

I really dont like the idea of having a GUI built into the server itself, not just from the performance angle but a management one, say you decide to run 5 game servers, you end up with a minimum of 6 separate GUIs, from a management point of view this makes it far more complex to manage than if it were a separate application.

Quote:

Originally Posted by Korvacs I really dont like the idea of having a GUI built into the server itself, not just from the performance angle but a management one, say you decide to run 5 game servers, you end up with a minimum of 6 separate GUIs, from a management point of view this makes it far more complex to manage than if it were a separate application.

I like the idea of a separate application that manages all of the servers, but my servers won't be on the same hosts. I can't use pipes like you do in your project. I don't think I'll ever have more than one server anyways. People will DDOS me out of existence. And I see the performance thing as insignificantly small. Is there something I'm missing that I haven't addressed?

Quote:

Originally Posted by Fаng I think I get it. You all aren't concerned about having a GUI, you all are concerned that I don't know how to implement a GUI successfully. If the server was lagging, it wouldn't be the GUI's fault. That's not only because it's rare that the draw method is called, I dedicate a thread to the GUI. When I want to write a line to the "console", I invoke the thread. I tell the textbox holding the console lines to begin writing the line: "_outputTextBox.BeginInvoke(_writer, line);" It will never block the server. The COM threading model of the server is MTA. It's defined as an attribute on the main function. The server's thread is of the highest priority, while the GUI thread is not. The performance loss of having the GUI is so insignificant. The benefits of having the GUI and the ability for me to show my server in action to my professors in a clean way, outweigh the insignificant costs of running it.

If you are not open to other people ideas, criticism and so on, why do you have a thread?

All I have seen is you saying no to every single opinion that has been provided, unless it is something that supports you.

I will keep thinking, a GUI will never overweight the performance cost, yet I know you will stay with your ideas, so I'll simply stop providing my feedback on a thread you have to "get" and deny every possible user feedback you get

sorry fangs but i think john got a point at what he said earlier

Quote:

Originally Posted by JohnHeatz If you are not open to other people ideas, criticism and so on, why do you have a thread? All I have seen is you saying no to every single opinion that has been provided, unless it is something that supports you. I will keep thinking, a GUI will never overweight the performance cost, yet I know you will stay with your ideas, so I'll simply stop providing my feedback on a thread you have to "get" and deny every possible user feedback you get

I'm ignoring things that have nothing to do with the performance of the server. I just asked Jack about the GUI problem in my last post and I'm hoping that he'll be able to provide me with evidence that this is a significant issue. The way I see it, nobody's been able to SHOW me that having a GUI greatly influences the server (using the model I've implemented). I'm not going out of my way to tear my project's GUIs apart without good reason.

Without seeing and analysing your model theres no telling from our point of view if the GUI influences the server's processing, so your asking for the impossible.

An alternative to pipes is simply a socket connection and while you dont think your going to provide more than 1 server your coding in a limitation which, if the situation changes in the future will hinder you significantly. A prime example of where this situation will change is when you want a test server aswell as a public server, automatically your hindered.

As for performance it really depends what you want to do with the GUI, if you want to read any data about memory stored on the server then you'll need to thread it extremely carefully to ensure that you dont block server processing, at this point like i said its impossible for us to tell what you want to do so commenting on performance specific to your situation isnt possible. The rule of thumb however is that GUI's hinder performance, from practically all angles.

Third part management removes all disadvantages.

Quote:

Originally Posted by Fаng I like the idea of a separate application that manages all of the servers, but my servers won't be on the same hosts. I can't use pipes like you do in your project. I don't think I'll ever have more than one server anyways. People will DDOS me out of existence. And I see the performance thing as insignificantly small. Is there something I'm missing that I haven't addressed?

What stops them just DDoSing two servers? Without a gameserver the authserver is pointless. without an authserver the gameserver is pointless.

So really, They STILL only have to take out one server to hinder the entire server.

Quote:

Originally Posted by _DreadNought_ What stops them just DDoSing two servers? Without a gameserver the authserver is pointless. without an authserver the gameserver is pointless. So really, They STILL only have to take out one server to hinder the entire server.

The gameserver can run without the authserver, however nobody can login afterwards. Which means all players logged can still play.

Attacking the gameserver will effect both though, so...

Splitting them will not help against ddosing nor is there anything that really can.

Quote:

Originally Posted by Korvacs Without seeing and analysing your model theres no telling from our point of view if the GUI influences the server's processing, so your asking for the impossible. An alternative to pipes is simply a socket connection and while you dont think your going to provide more than 1 server your coding in a limitation which, if the situation changes in the future will hinder you significantly. A prime example of where this situation will change is when you want a test server aswell as a public server, automatically your hindered. As for performance it really depends what you want to do with the GUI, if you want to read any data about memory stored on the server then you'll need to thread it extremely carefully to ensure that you dont block server processing, at this point like i said its impossible for us to tell what you want to do so commenting on performance specific to your situation isnt possible. The rule of thumb however is that GUI's hinder performance, from practically all angles. Third part management removes all disadvantages.

Well, I compared Project Kibou with and without a GUI. Kibou's ability to run a server doesn't change significantly enough to show up on a high resolution timer. I just noticed though that the GUI is being run on the main thread, which might cause some priority issues. I'll be changing that within the next few days. It's always possible that I just forget about C# entirely and make my server in C++ as a console application... but I don't necessarily want to restart. I've wasted enough time and effort restarting.

Quote:

Originally Posted by I don't have a username The gameserver can run without the authserver, however nobody can login afterwards. Which means all players logged can still play. Attacking the gameserver will effect both though, so... Splitting them will not help against ddosing nor is there anything that really can.

My goal wasn't to prevent ddos attacks. My goal was to keep the servers separated. That way, I could support multiple servers (even though I don't want multiple servers right away). I should be thinking more about that as Jack said.

The problem is you wont know how your GUI effects your server without it being moderately populated, otherwise there's nothing to block in all likelihood.

Quote:

Originally Posted by Korvacs The problem is you wont know how your GUI effects your server without it being moderately populated, otherwise there's nothing to block in all likelihood.

Hmm... I see. I'm trying to find points where the GUI would block up the server. The GUI could block it up if I cross-thread or do a lot of processing; however... I don't cross-thread and I keep processing to background workers. It should be a non-blocking system. If the GUI is closed, the server socket system is still in tact until I shut it down and close the program. Server processing is on it's own MTA thread. If the GUI freezes, it shouldn't hinder server processing at all. That's because I invoke everything in the GUI using non-blocking methods. Nothing server related ever touches the GUI without using a non-blocking invoke. If my GUI is frozen, it would only freeze that thread. Hmm... It has no reason to freeze as far as I'm aware. I test the GUI very thoroughly, but there's always that possibility that I missed something. I still don't think I could remove the GUI though. It makes server management so much easier for people to understand (being able to interact with a GUI). It's easier to show my professors what the program is capable of, too. I'll just have to keep using safe methods and test it very thoroughly.

Let me congratulate you to work as hard as you do on your project. The post is usually updated and your explanations always accurate.

Wish you good luck, keep-it up!