Archive for the ‘SmartFoxServer 2X’ Category

Why ScheduledThreadPoolExecutor for SmartFoxServer 2X

March 14th, 2011 by admin | 3 Comments | Filed in ScheduledThreadPoolExecutor

Generally In the game logic timers are required to be used in various situations. Instead of Timer SFS2X runs ScheduledThreadPoolExecutor’s instance wrapped in a class called TaskScheduler why ?

Lets discuss :

What is ScheduledThreadPoolExecutor ?

A public class ScheduledThreadPoolExecutor extends to ThreadPoolExecutor and implements ScheduledExecutorService

A ThreadPoolExecutor is able to additionally schedule commands to run after a specific delay, or to execute periodically. It  is preferable when multiple worker threads are needed, or when the additional flexibility or capabilities f ThreadPoolExecutor are required.

In this case how the tasks executes ? :

Delayed tasks execute when they are enabled. Tasks scheduled for exactly the same execution time are enabled in first-in-first-out (FIFO) order of submission.

What are differences between Timers and ScheduledThreadPoolExecutor ?

1. Timer can be sensitive to changes in the system clock, ScheduledThreadPoolExecutor  is not.

2. Timer has only one execution thread, so long-running task can delay other tasks.

3. ScheduledThreadPoolExecutor can be configured with any number of threads.

4. ScheduledThreadExecutor not only catches runtime exceptions, but it lets you handle Task which threw exception will be canceled, but other tasks will continue to run.

6  ScheduledThreadExecutor isn’t available in Java 1.4 library

UDP protocol with SmartFoxserver 2X and its restrictions

March 11th, 2011 by admin | 2 Comments | Filed in UDP protocol and SmartFoxserver 2X

Although the default protocol is TCP , now SmartFoxServer 2X is also supporting UDP for clients like Unity3D and AIR 2.0 for Flash developer.

Why Support for UDP  ? :

To achieve higher performance, the protocol allows individual packets to be dropped (with no retries) and UDP packets to be received in a different order than they were sent as dictated by the application.

Differences in between TCP and UDP :

TCP offers error correction. When the TCP protocol is used there is a “guaranteed delivery.” This is due a method called “flow control.” Flow control determines when data needs to be re-sent, and stops the flow of data until previous packets are successfully transferred. This works because if a packet of data is sent, a collision may occur. When this happens, the client re-requests the packet from the server until the whole packet is complete and is identical to its original.
However, UDP is never used to send important data such as webpages, database information, etc;

UDP is commonly used for streaming audio and video because it offers speed! The reason UDP is faster than TCP is because there is no form of flow control or error correction. The data sent over the Internet is affected by collisions, and errors will be present. UDP is only concerned with speed. This is the main reason why streaming media is not high quality.

UDP restrictions for Flash

As you can notice from the above snippet of code the initUDP method takes an argument:

sfs.initUDP(new AirUDPManager())

Adobe’s support for UDP is in fact only available for standalone applications based on the AIR runtime(version 2.0 and higher) while no support is provided for Flash and Flex applications running in the browser.

In order to be able to support SFS2X introduced the AirUDPManager class .

Tags: , , , , , , , , , ,

Threading model of SmartFoxServer 2X for Server side Extensions

March 10th, 2011 by admin | 7 Comments | Filed in Threading model of SmartFoxServer 2X

SmartFoxServer 2X runs all Extensions in a multithreaded environment. In a thread-based multitasking environment, the thread is the smallest unit of dispatchable code. Because a program can contain more than one thread, a single program can use multiple threads to perform two or more tasks at once.

Multithreading is important for these main reasons :

  1. Multithreading enables to write very efficient programs because it lets utilize the idle time that is present in most programs. Most I/O devices, whether they be network ports, disk drives, or the keyboard, are much slower than the CPU. Thus, a program will often spend a majority of its execution time waiting to send or receive information to or from a device. Multithreading program can execute another task during this idle time.
  2. While one part of a program is sending a block of data to the server/client still another can be buffering the next block of data to send.
  3. Multithreading is relates to Java’s eventhandling model. A program must respond quickly to an event and then return. An event handler must not retain control of the CPU for an extended period of time. If it does, other events will not be handled in a proper manner. This will make an application appear Slow-moving or inactive. It is also possible that an event will be missed. Therefore, if an event requires some extended action, then it must be performed by a separate thread.

Because of above mentioned  reason there are fundamentally two separate thread pools operating on an Extension of SFS2X:

a).  the ExtensionController (Which Handles Client Requests)

b) . the EventManager. (Which  Dispatches the server events)

Synchronization of Shared State

A thread can be in one of several states. It can be running. It can be ready to run as soon as it gets CPU time. A running thread can be suspended, which is a temporary halt to its execution. It can later be resumed. A thread can be blocked when waiting for a resource. A thread can be terminated, in which case its execution ends and cannot be resumed.Since in the case of SFS2X threads operate concurrently on the Extension code access of shared state should be properly synchronized. Although The SFS2X API already take care of of these points.

Tags: , , , , , , , , , , , ,

Enterprise level applications architecture of SmartFoxServer 2X

March 9th, 2011 by admin | 1 Comment | Filed in Enterprise level applications architecture, SmartFoxServer 2X

SmartFoxServer 2X Extensions have dropped support for scripting languages and concentrated on the Java extension development. The main reasons are:

The New server architecture is oriented to enterprise-level applications where this architecture have  following patterns :

  1. Handles A lot of persistent data
  2. Handles  concurrent data access
  3. Handles  A lot of user interface screens/ High Load
  4. Handles  Integrate with other enterprise applications
  5. Handles  Lots of translation between data formats (usually for integration or reporting)
  6. Handles  Critical performance. Often includes cluster support
  7. Handles  Multi-platform — usually a minimum of Windows, Linux
  8. Handles  Support many different configurations, including databases
  9. Handles  Must support many different configurations, including databases

To fulfill above requirement the best language is Java which highly supports these features therefore it is now used for the server side

Extension