While I'm currently writing this, I'm also
watching the official trailer of the up coming Nintendo Switch and at the same time chatting
to some of my friends on Google+, Oh yeah, and there's a lot of other
application currently open at my desktop, including visual studio where
I'm currently working on my communicator project. Wow! so this is what
they call multitasking on windows, running multiple applications at the
same time
Nah, I don't think all of those things are running at the same time. My perception is that the OS just slices up the processor's time to process each task, giving each and every active program application to run in it's own slice time for a given period, say per second and since I'm currently using an old computer station that does not have a multi-core processor, basically the computer is just doing it's tasks so fast, repeatedly, giving an illusion that everything is happening simultaneously.
So, How's all the above babbling related to networking? the thing is a .NET program can also be consider like a virtual machine, in the sense that it can handle multiple tasks and gets some slice of processor's time, Coz "usually we don't want to performs socket processing operation to block our main application logic for running continously". The .NET Frameworks gave us the ability to do multi-threading for our application, whether it's a dedicated thread or an asynchronous events using it's CLR thread pool.
If your using .NET technology on windows platform, well, your in luck, whether you are using a dual core/ tri core or quad core processors, you don't have to do a thing or tweak anything in the code, the OS will managed all the threading stuff to work on different cores automagically.
Apparently from my previous post, the SenderMode does not have an option for dedicated thread, while both AcceptorMode and ReceiverMode has the ability to do it's processing on a dedicated thread. Normally, the application has a full control when sending data, unlike listening for incomming connection or waiting for data to arrive, we cannot exactly tell when the data will arrive, So basically, as much as possible we really need to monitor all incomming connection or data at all time, we dont want to miss a single incomming packet, dont we?
So, what is the best method for socket processing? again, in my implementation, it really depends on the nature of the application objectives or game type, the following diagram for socket processing scheme are just some of the variety that can be implemented by just changing the socket core's enumerated processing mode for Listening, Receiving and Sending data.
I'll post next the some image of Managed Network's Socket Processing Scheme features.
Nah, I don't think all of those things are running at the same time. My perception is that the OS just slices up the processor's time to process each task, giving each and every active program application to run in it's own slice time for a given period, say per second and since I'm currently using an old computer station that does not have a multi-core processor, basically the computer is just doing it's tasks so fast, repeatedly, giving an illusion that everything is happening simultaneously.
So, How's all the above babbling related to networking? the thing is a .NET program can also be consider like a virtual machine, in the sense that it can handle multiple tasks and gets some slice of processor's time, Coz "usually we don't want to performs socket processing operation to block our main application logic for running continously". The .NET Frameworks gave us the ability to do multi-threading for our application, whether it's a dedicated thread or an asynchronous events using it's CLR thread pool.
If your using .NET technology on windows platform, well, your in luck, whether you are using a dual core/ tri core or quad core processors, you don't have to do a thing or tweak anything in the code, the OS will managed all the threading stuff to work on different cores automagically.
Apparently from my previous post, the SenderMode does not have an option for dedicated thread, while both AcceptorMode and ReceiverMode has the ability to do it's processing on a dedicated thread. Normally, the application has a full control when sending data, unlike listening for incomming connection or waiting for data to arrive, we cannot exactly tell when the data will arrive, So basically, as much as possible we really need to monitor all incomming connection or data at all time, we dont want to miss a single incomming packet, dont we?
So, what is the best method for socket processing? again, in my implementation, it really depends on the nature of the application objectives or game type, the following diagram for socket processing scheme are just some of the variety that can be implemented by just changing the socket core's enumerated processing mode for Listening, Receiving and Sending data.
I'll post next the some image of Managed Network's Socket Processing Scheme features.
No comments:
Post a Comment