Syncing Your GitHub Fork

.

If you have forked a project on GitHub, you will have your own copy of the project in your GitHub account. Your copy will not be automatically synced with the original. Follow these simple steps to sync your repo with the original repo:

Assuming you have your fork on your local computer (local clone of the fork is created using git clone command). Add the remote upstream:

# git remote add upstream $originalRepoURL

Check the remote URL: # git remote -v

You will see the URLs of the fork and the original.

Now fetch the upstream: # git fetch upstream

Check out the local master branch of the fork: # git checkout master

Doing this you will be switched to the local master branch of the fork.

Merge the changes. Assuming you want to merge the local master branch of the fork with the master branch of the upstream: # git merge upstream/master
Push the changes to your GitHub copy: # git push origin master

Enter your credentials and check the update on GitHub.

---

I/O Design Patterns For SIP Routers

.

 

In real-time applications like SIP applications, we have a lot of IO operations (database IO operations, network IO operations,…etc.) and the time to accomplish each IO operation is critical. Using event based architecture with asynchronous IO minimizes the time of IO operation and scale up the performance.

Here i just would like to explain the concept of reactor and proactor patterns for I/O operations. Both the reactor and proacor depend on event firing but the difference who is doing the actual IO operations.

Reactor Pattern

The reactor pattern involves synchronous I/O. The event here is defined as “ready to read or write”. When this kind of IO event is fired, the event demultiplexer passes the event to the registered user event handler/callback. The user event handler/callback function will be called to do the actual IO operation (read or write).

Proactor Pattern

The proactor IO pattern involves asynchronous IO. The event here is defined as “read or write is completed“. When this kind of IO event is fired, the user callback function/event handler will be called to process the data if the operation was “read” and do something else (new async operation) if the operation was “write”. Here the actual IO operation is done by one of the kernel threads which does the actual IO operation using a user defined buffer passed to it when the asynchronous system call is done. When the kernel finished the IO operation, it notifies the event demultiplexer and this will pass the event to the user handler/callback. As you can see the operating system must support the asynchronous IO so it can use the user buffer to do the actual IO operation to save the user application time.

---

.