Ruminating on Network Port Mirroring

For any network sniffer (analyzer) or Network Intrusion Detection Systems to work, the concept that is applied behind the scenes is 'Network Port Mirroring'.

Port mirroring is needed for traffic analysis on a switch because a switch normally sends packets only to the port to which the destination device is connected. Hence most switches support configuring a 'port mirroring' to send a copy of each network packet to an other port (local port or a separate VLAN port).

The following links are worth a perusal.
http://searchnetworking.techtarget.com/definition/port-mirroring

https://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/port-mirroring-qfx-series-understanding.html

Updating content in an iOS app

Any mobile app needs to have a design strategy for updating content from the server. We were exploring multiple options for retrieving content from the server and updating the local cache in our iOS app.

After considerable research, we have found that iOS 7 provides a very neat design for background fetching of new content - one that uses silent push events to raise events in the client app. Even if the app is not running, it would be launched in the background (with UI invisible, rendered off-screen) to process the event. The following article gives a very good overview of the technique.

http://www.objc.io/issue-5/multitasking.html

Some snippets from the above article:

A Remote Notification is really just a normal Push Notification with the content-available flag set. You might send a push with an alert message informing the user that something has happened, while you update the UI in the background. 
But Remote Notifications can also be silent, containing no alert message or sound, used only to update your app’s interface or trigger background work. You might then post a local notification when you’ve finished downloading or processing the new content. 

 iOS 7 adds a new application delegate method, which is called when a push notification with the content-available key is received. Again, the app is launched into the background and given 30 seconds to fetch new content and update its UI, before calling the completion handler.

How is the App launched in the background? 
If your app is currently suspended, the system will wake it before callingapplication: performFetchWithCompletionHandler:. If your app is not running, the system will launch it, calling the usual delegate methods, includingapplication: didFinishLaunchingWithOptions:. You can think of it as the app running exactly the same way as if the user had launched it from Springboard, except the UI is invisible, rendered offscreen.