تبليغاتX
XGRID تکنولوژی
 
XGRID تکنولوژی
 
 
پیاده سازی سیستم های توزیع شده
 


(thread)و سیستمهای multitasking

در تکنیک چندنخی (multitasking) یک فرایند (process) که برنامهای در حال اجراست , میتواند به بخشها یا نخهایی (بندهایی ) تقسیم شود که میتوانند به صورت همزمان اجراء شوند.
برنامههایی که چند وظیفه مستقل از هم را انجام میدهند میتوانند به صورت چن نخی نوشته شوند. گاهی اوقات به سیستمهای multithreading سیستمهای چند تکلیفی یا چند وظیفه ای (multitasking)هم گفته میشود.
فرآیند (process)یا پردازش اساس یک برنامه در حال اجراست که منابعی از سیستم به آن تخصیص داده شده است (شامل رجیسترها,حافظه,فایلها و دستگاهها).فرآیند میتواند مجموعهای از یک یا چند نخ باشد. به نخ, رشته یا بند هم گفته میشود . کلیه اطلاعات مربوط به هر پروسس , در یکی از جداول سیستم عامل به نام جداول Process Control Block=PCB ذخیره میشود. این جدول یک آرایه یا لیست پیوندی از ساختارهاست که هر عضو آن مربوط به یکی از پروسسهاست که در حال حاضر موجودیت دارد.
اطلاعات موجود در PCB عبارتند از : حالت جاری پردازش ,شماره شناسایی پردازش , اولیت پردازش , نشانی حافظه پردازش , نشانی محل برنامه پردازش بر روی دیسک , نشانی سایر منابع پردازش , محلی برای حفظ ثباتها .

منبع :شبه رشد

 

 |+| نوشته شده در  شنبه سی و یکم فروردین 1387ساعت 5:42 بعد از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

A Virtual Infrastructure Layer for Cluster and Grid Computing

Cluster, and so Grid site, administrators have to deal with the following requirements when configuring and scaling their infrastructure:

  • Heterogeneous configuration demands. Users often require specific versions of different software components (e.g. operating system, libraries or post-processing utilities). The cost of the installation, configuration and maintenance of user-specific or VO-specific worker nodes limits the flexibility of the infrastructure.
  • Performance partitioning. Most of the computing infrastructures do not allow administrators to isolate and partition the performance of the physical resources  they devote to different computing clusters or Grid infrastructures. This limits the quality of service and reliability of actual computing platforms, preventing a wide adoption of the Grid paradigm.

In order to overcome these challenges, we propose a new virtualization layer between the service and the physical infrastructure layers, which seamless integrates with existing Grid and cluster middleware stacks. The new virtualization layer extends the benefits of VMMs (Virtual Machine Monitors) from a single physical resource to a cluster of resources, decoupling a server not only from the physical infrastructure but also from the physical location. In the particular case of computing clusters, this new layer supports the dynamic execution of  computing services, working nodes, from different computer clusters on a single physical cluster.


layers.png

OpenNebula is the name of a new open-source technology that transforms a physical infrastructure into a virtual infrastructure by dynamically overlaying VMs over physical resources. So computing services, such as working nodes managed by existing LRMs (Local Resource Managers) like SGE, Condor, OpenPBS..., could be executed on top of the virtual infrastructure; so allowing a physical cluster to dynamically execute multiple virtual clusters.

The separation of resource provisioning, managed by OpenNebula, from job execution management, managed by existing LRMs, provides the following benefits:

  • Cluster consolidation because multiple virtual working nodes can run on a single physical resource, reducing the number of physical systems and so space, administration, power and cooling requirements. The allocation of physical resources to virtual nodes could be dynamic, depending on its computing demands, by leveraging the migration functionality provided by existing VMMs
  • Cluster partitioning because the physical resources of a cluster could be used to execute virtual working nodes bound to different virtual clusters
  • Support for heterogeneous workloads with multiple (even conflicting) software requirements, allowing the execution of software with strict requirements as jobs that will only run with a specific version of a library or legacy application execution

Consequently, this approach provides the flexibility required to allow Grid sites to execute on-demand VO-specific working nodes and to isolate and partition the physical resources. Additionally, the architecture offers other benefits to the administrator of the cluster, such as high availability, support for planned maintenance and changing capacity availability, performance partitioning, protection against malicious use of resources...

The idea of a virtual infrastructure which dynamically manages the execution of VMs on physical resources is not new. There exist several VM Management proprietary solutions to simplify the use of virtualization, so providing the enterprise with the potential benefits this technology may offer. Examples of products for the centralized management of the life-cycle of a VM workload on a pool of physical resources are: Platform VM Orchestrator, IBM Virtualization Manager, Novell ZENworks, VMware Virtual Center, and HP VMManager.

The OpenNebula Virtual Infrastructure Engine differentiates from those VM management systems in its highly modular and open architecture  to meet the requirements of cluster administrators. The OpenNebula Engine provides a command line interface for monitoring and controlling VMs and physical resources quite similar to that provided by well-known LRMs. Such interface allows its integration with third-party tools, such as LRMs, service adapters, VM image managers...; to provide a complete solution for the deployment of flexible and efficient computing clusters. The service layer decoupling from the infrastructure layer allows an straightforward extension of the previous idea to any kind of service. In this way any physical infrastructure can be transformed into a very effective provisioning platform.

A Technology Preview of OpenNebula is available for download under the terms of the Apache License, version 2.0.

Ignacio Martín Llorente
Reprinted from blog.dsa-research.org

منبع : http://gridgurus.typepad.com

 

 |+| نوشته شده در  پنجشنبه بیست و نهم فروردین 1387ساعت 11:14 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

My favorite grid application

tacc.jpg

My esteemed Grid Gurus moderator, Rich Wellner, asked "what is the most creative use for grid technology that you've ever seen?" This is a difficult question to answer, but I will attempt to do so anyway.

I choose the work of George Karniadakis, Suchuan Dong, Nick Karonis, and their colleagues on modeling blood flow in the human body. Why I like it is the wacky (sorry, wonderful) way in which they mapped this apparently highly tightly coupled problem onto the distributed sites of the NSF TeraGrid. Quoting  one of their papers:

Motivated by a grand-challenge problem in biomechanics, we are striving to simulate blood flow in the entire human arterial tree. The problem originates from the widely accepted causal relationship between blood flow and the formation of arterial disease such as atherosclerotic plaques. These disease conditions preferentially develop in separated and recirculating flow regions such as arterial branches and bifurcations. Modeling these types of interactions requires significant compute resources to calculate the three-dimensional unsteady fluid dynamics in the sites of interest. Waveform coupling between the bifurcations, however, can be reasonably modeled by a reduced set of one-dimensional
equations that capture the cross-sectional area and sectional velocity properties. One can therefore simulate the entire arterial tree using a hybrid approach based on a reduced set of one-dimensional equations for the overall system and detailed 3D Navier-Stokes equations at arterial branches and bifurcations.

In other words, they mapped different parts of the human body (chest, legs, arms, head, and their arterial branches) to different TeraGrid sites, linking them by a simple, non-communication intensive 1-D problem.

The tools used to make this happen were MPICH-G2 (recently renamed as MPIG) and of course Globus.

منبع : http://gridgurus.typepad.com

 

 |+| نوشته شده در  پنجشنبه بیست و نهم فروردین 1387ساعت 11:13 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

The Canon of Clouds

clouds_000003876801XSmall.jpgThe emergence of cloud computing as a resource on the grid has led to a huge resurgence in interest in utility computing. Looking at the history of utility computing allows us to identify three canonical interaction models that also apply to cloud computing.

  • Metascheduling
  • Virtual machines
  • Application virtualization

Metascheduling

Initial cloud offerings like Amazon Elastic Compute Cloud created the nomenclature around clouds. Going back before the term "cloud" was coined we see a similar offering from Sun with their utility computing offering. In both cases users submit work to the service and eventually get results returned. How the request gets prioritized, provisioned and executed is at the discretion of the service provider. In many ways this is similar to how a typical cluster works. A user selects a cluster, submits a job and waits for a response. What node is used to execute his request is largely out of his control. While acknowledging there are substantial difference between a cluster and a cloud, another similarity reveals itself when thinking about how users interact with compute resources in companies that operate multiple clusters.

As companies began adding additional clusters, users quickly demanded a facility to submit their jobs to a high level service that would manage the interactions with all the clusters that were available. Most users didn't want to have to themselves use multiple monitoring tools to access multiple clusters and use the information gathered to make a decision about where to submit their job. What they wanted was a single interface to submit jobs to and a service that would make policy based decisions about which cluster to ultimately submit the request.

The situation today is similar. Multiple cloud and utility computing vendors exist and users don't want to spend their time gathering information about the state of each in order to decide where to submit their jobs. Further, administrators and managers need to be able to enforce policy. There are several reasons for requiring this behavior, but probably the easiest to explain is that there are costs associated with resource usage at the cloud vendors and organizations require control over how that money is spent.

The answer to all these needs is to place a metascheduler between the users and the various resources. Users can then use a single interface for all their jobs regardless of where they are ultimately going to be executed.

[A metascheduler] enables large-scale, reliable and efficient sharing of computing resources (clusters, computing farms, servers, supercomputers…), managed by different LRM (Local Resource Management) systems, such as PBS, SGE, LSF, Condor…, within a single organization (enterprise grid) or scattered across several administrative domains (partner or supply-chain grid). -- GridWay

Virtual machines

Clouds are only as useful as the software running in them. Therefore, the next important interaction model is that between users and virtual machines.

Users often need very specific software stacks. This includes the application they are running, support libraries and, in some instances, specific versions of operating systems. Analysts are saying that there are now at least 35 companies addressing the needs of users in managing these interactions. This includes software to implement the enactment layer, manage images, policy engines, user portals and analytics functions.

One of the questions yet to be answered in the cloud community is how to allow users to make use of several clouds on a day to day basis. As this market continues to mature, look for many of the same challenges (e.g. security, common APIs, WAN latencies) that the grid community has been tackling for over a decade to become increasingly important to cloud users.

Application virtualization

In the context of clouds, application virtualization gains significant power by being able to add or remove instances of applications on demand. This is currently being done in the context of data center management using proprietary tools. Clouds present a cool new opportunity to do the balancing act on a regional basis. As more clouds are built and standard interfaces made available, users will be able to load balance to multiple clouds operating in different countries or cities as demand grows and shrinks.

These three models represent established, powerful interaction modes that are being used in production in a variety of settings today. It will be interesting over the next year to see which cloud operators adopt which models and how many lessons they take from existing non-cloud implementation versus trying to reinvent the wheel in a new way.

منبع : http://gridgurus.typepad.com

 

 |+| نوشته شده در  پنجشنبه بیست و نهم فروردین 1387ساعت 11:12 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

Grid Engine 6.1u4 Release

code_000000237891Small.jpgThe Grid Engine project has announced a new maintenance release (version 6.1 Update 4) of its software. This release fixes some 50+ issues found in earlier versions. In particular, couple of problems causing qmaster crashes have been resolved, and so were several dbwriter and accounting issues. More specifically, if you were wondering why your array job task usage is missing from the accounting file, you should consider installing this release. The new version of the software is available for download here.
 
 
 
منبع : http://gridgurus.typepad.com
 
 
 |+| نوشته شده در  پنجشنبه بیست و نهم فروردین 1387ساعت 11:9 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

UniCluster 3.2 Released

code_000000237891Small.jpgThe grid.org team has just declared UniCluster 3.2 to be stable.

  • Users can now install UniCluster Express over an existing Grid Engine installation.
  • Expanded platform and operating support, including native 64-bit system support.
  • The installation directory and service user are now created at installation, if they do not exist already.
  • Removed several installation prerequisites, making installation easier and faster.
  • Maintenance in the form of defect repairs. Refer to bugzilla for specific details.

In particular, being able to install over an existing Grid Engine installation is super cool. This is a feature that I've been excited about for a long time as it brings globus, ganglia and the UniCluster monitoring application to the existing 10,000 or so Grid Engine clusters.

Download

منبع : http://gridgurus.typepad.com

 

 |+| نوشته شده در  پنجشنبه بیست و نهم فروردین 1387ساعت 11:6 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

MPI vs. Compiler

Marlborough, MA, ? April 01, 2008 ? Scali, the leader in higher performance computing software, today announced new benchmark results provided by Scali using the SPEC MPI2007 benchmark suite on the newly released Scali MPI Connect version 5.6.1. As of today?s release, Scali cements its leadership and has the highest SPECmpiM_base2007 score for all systems ranging from 32 to 128 cores. Further, as a courtesy to the industry, Scali has submitted results using different compilers, enabling studies of which cluster components truly provide differential performance benefits. For a 32-node cluster system using 128 cores, the results show the compiler difference to be a modest 6 percent. However, on similarly equipped systems, these new results show that Scali MPI Connect extracts 18 percent more performance than HP-MPI (1).

?It is our top priority to deliver the best performing MPI in the industry and the newly submitted results underscore that commitment. Out of the 13 applications which constitute the SPEC MPI2007 medium suite running on 32 nodes and 128 cores, three of the applications performed within +/- 2 percent as compared to a similar system using HP-MPI. All the other 10 applications perform significant faster with Scali MPI Connect. For example the Quantum Chemistry application Socorro performs 21 percent faster with Scali MPI Connect. Additionally, the result for the POP2 benchmark, a climate modeling test using the Parallel Ocean Program (POP) showed a 336 percent performance advantage over the HP-MPI based system.?, said Hakon Bugge, CTO of Scali. ?We will continue our leadership role in providing the HPC community with the data they need to make important technology decisions. The choice is clear, over all; Scali MPI Connect is the best performing MPI in the market.?

SPEC MPI2007

SPEC MPI2007 is SPEC's benchmark suite for evaluating MPI-parallel, floating point, and compute intensive performance across a wide range of cluster and SMP hardware. MPI2007 continues the SPEC tradition of giving HPC users the most objective and representative benchmark suite for measuring the performance of SMP (shared memory multi-processor) systems. SPEC reviews and publishes submitted results on their website at: http://www.spec.org/mpi2007/results/ . SPEC? and the benchmark name SPEC MPI? are registered trademarks of the Standard Performance Evaluation Corporation. Competitive benchmark results stated above reflect results published on www.spec.org as of April 1, 2008.

About Scali and Scali MPI Connect

Founded in 1997, Scali is the leading developer of a fully integrated message passing interface (MPI) library that enables companies to take advantage of premier interconnect technologies to build high performance clusters. Scali MPI Connect is designed to enable applications to run at maximum performance through its unique, high performance, patent pending technology. Scali MPI Connect supports a wide range of customer environments while lowering the number of binaries required, and delivers superior application performance. Hundreds of companies, including Goodyear, Daimler AG, Lockheed Martin, US Army and Naval Air, Schlumberger and Shell benefit from using Scali?s MPI libraries. The company is headquartered in Marlborough, Massachusetts with research and development in Oslo, Norway and Nagpur, India. Visit http://www.scali.com for more information.

? 2008 Scali, Inc., All rights reserved. Scali and Scali MPI Connect are trademarks of Scali, Inc. All other service marks, trademarks, and registered trademarks are the property of their respective owners.

(1) The two systems labeled ? HP Proliant BL460c blade Cluster Platform 3000BL? and ? LS-1, Scali MPI Connect 5.6.1, Intel 9.1 compilers?, are both using Mellanox based Infiniband DDR HCAs, dual-core Intel Xeon 5160 processors and Intel 9.1 compilers. Using 32 nodes and 128 cores, the HP-MPI based system delivers a SPECmpiM(TM)_base2007 score of 11.9. The Scali MPI Connect based system delivers 14.0 using the same metric, i.e., 18 percent higher score.

منبع : http://www.linuxhpc.org/stories.php?story=08/04/10/8378717

 

 |+| نوشته شده در  پنجشنبه بیست و نهم فروردین 1387ساعت 10:49 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

An Introduction To Distributed Intrusion Detection Systems

What is a dIDS?

A distributed IDS (dIDS) consists of multiple Intrusion Detection Systems (IDS) over a large network, all of which communicate with each other, or with a central server that facilitates advanced network monitoring, incident analysis, and instant attack data. By having these co-operative agents distributed across a network, incident analysts, network operations, and security personnel are able to get a broader view of what is occurring on their network as a whole.

A dIDS also allows a company to efficiently manage its incident analysis resources by centralizing its attack records and by giving the analyst a quick and easy way to spot new trends and patterns and to identify threats to the network across multiple network segments. This article will discuss distributed intrusion detection systems, including the general setup of a dIDS and a fictional case study to demonstrate the distributed analysis abilities. It will also try to give the reader some insight into the benefits of running a dIDS system, from both incident analyst and corporate views.

Overview

The Central Analysis Server

The central analysis server is really the heart and soul of the operation. This server would ideally consist of a database and Web server. This allows the interactive querying of attack data for analysis as well as a useful Web interface to allow the corporate guys upstairs to see the current attack status of your network. It also allows analysts to perform pre-programmed queries, such as attack aggregation, statistics gathering, to identify attack patterns and to perform rudimentary incident analysis, all from a Web interface.

The Co-operative Agent Network

The co-operative agent network is one of the most important components of the dIDS. An agent is a piece of software that reports attack information to the central analysis server. The use of multiple agents across a network allows the incident analysis team a broader view of the network than can be achieved with single IDS systems.

Ideally these agents will be located on separate network segments, and geographical locations (See diagram below.) The agents can also be distributed across multiple physical locations, allowing for a single incident analysis team to view attack data across multiple corporate locations.

Although any IDS could be used on the agent machines, it is highly suggested that Snort be used. It has been demonstrated, however, that any attack logging system can be incorporated into this agent network. This can range from router attack logs, to ipfw, firewalls, and even Windows personal firewall systems.

Attack Aggregation

Attack aggregation is another core part of the dIDS system. This part of the system is programming logic based on the central server. Aggregation simply refers to the method in which users group or order the information gathered from the agent network. One example of this would be to aggregate information according to attacker IP, putting all attacks from an attacking IP together with other attacks from the same IP. Another example is the aggregation of attack data according to destination (attacked) port, or even by date and time. Uses for aggregation will be explained later in this paper.

Advantages of a dIDS

Why a dIDS?

Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred.

The second major advantage is that a single analysis team can now do what previously required several incident analysis teams due to physical distance. This obviates the need to pay for distinct incident analysis teams for each separate geographic location of the organization’s offices. Another issue that it addresses is attacks from within the corporations network by angry, upset, or bored employees. By tying the central analysis server in with the companies DHCP or RADIUS servers, the incident analysts can track down people launching attacks from within the company, and track what they have attempted to do, as well as provide evidence against the perpetrators.

Incident Analysis With dIDS

Incident analysis using the dIDS system is really what it is all about. This is where all the power, potential, flexibility, and strength of the system as a whole lies. It is the reason why the dIDS was first conceptualized, to allow for advanced analysis of attacks occurring over multiple network segments, and at an advanced level.

Analysis Using Aggregation

Aggregation is the main component used to facilitate this advanced method of analysis across a networks multiple segments. By aggregating similar or related data, the analyst is able to easily see how an attack progressed through the different stages: from active network reconnaissance, to the final attack. It is possible for the incident analyst to see what kind of time frame the attacker was working within and to correlate other attack attempts against the networks to determine if there were multiple co-operative attackers. The most common methods of aggregation are according to attacker IP, destination port, agent ID, date, time, protocol, or attack type.

  • Aggregating by attacker IP allows the analyst to view the steps of an attacker’s attempt from start to finish across the multiple network segments.
  • Aggregating by destination port allows an analyst to view new trends in attack types, and to be able to identify new attack methods, or exploits being used.
  • Aggregating by agent ID allows an analyst to see what variety of attacks and attackers have made attempts on the specific network segment the agent is on. Consequently, the analyst can determine if there are multiple attackers working in conjunction, or if there are network segments that are of more interest to attackers than others, thereby giving the security team a list of common targets to work on.
  • Aggregating by date and time allows the analyst to view new attack patterns, and to potentially identify new worms or viruses that are only triggered at certain times.
  • Aggregating by protocol helps in a purely statistical manner, which could allow an analyst to identify new attacks in particular protocols, or identify protocols on a network segment that should, under no circumstances, be there anyhow.
  • Aggregating by attack type also allows for attack pattern matching and to correlate coordinated attacks against multiple network segments.

By utilizing all of these aggregation methods, the analyst is given an unlimited number of different sets of data to correlate against other attacks, detect coordinated distributed attacks, attacks from within their own network, and to detect new exploits and vulnerabilities being deployed by the underground hacking community.

The broad view given by the dIDS system also allows the analyst to ensure a minimum of false positives and false negatives by being able to see beyond a single network segment, into the network as a whole. For example, if the analyst saw that one out of five network segments got seven unrequested ICMP Echo packets, it could be a simple issue of false addressing or improper routing somewhere. However, if the analyst were to see that three separate network segments were reporting seven unrequested ICMP Echo packets, it is much more likely that these packets would be malicious in nature. This would cause the analyst to take note of the activity and perhaps check into the incident further or flag it for review at a later date.

Analysis Case Study

You come into the office early one morning, boot up your PC, and surf to your Central Analysis server to see what has been going on throughout the night. First thing you do is check incident reports aggregated by the attackers IP. You notice that slews of probes were sent to two internal use IIS Web Servers, located at 172.16.2.106, and 172.16.1.98. These segments’ agent Ids are “Main Office.” and “Production” The following shows up on the incident report:

Source IP: 206.219.23.16
Attack Time Agent Alias Target IP # of Machines
Targeted
IP
Protocol
Target
Port
# of
Probes
25 Sep 2001 16:23:45 Main Office 172.16.2.106 1 6 80 12
25 Sep 2001 16:24:01 Production 172.16.1.98 1 6 80 12
25 Sep 2001 16:24:35 Main Office 172.16.2.106 1 6 27374 3
25 Sep 2001 16:24:01 Production 172.16.1.98 1 6 27374 3

Now we’ll want to see if any other attacks were attempted on either of these machines. So, we’ll aggregate the attack data by the target IP addresses, which are included in the previous report. Now we get two reports.

Target IP: 172.16.106
Attack Time Agent Alias Target IP # of Machines
Targeted
IP
Protocol
Target
Port
# of
Probes
25 Sep 2001 16:23:02 Main Office 24.26.198.98 1 6 21 3
25 Sep 2001 16:23:21 Main Office 24.26.198.98 1 6 137 5
25 Sep 2001 16:23:45 Main Office 206.219.23.16 1 6 80 12
25 Sep 2001 16:24:35 Main Office 206.219.23.16 1 6 27374 3

Target IP: 172.16.1.98
Attack Time Agent Alias Target IP # of Machines
Targeted
IP
Protocol
Target
Port
# of
Probes
25 Sep 2001 16:23:14 Production 24.26.198.98 1 6 21 3
25 Sep 2001 16:23:29 Production 24.26.198.98 1 6 137 5
25 Sep 2001 16:24:01 Production 206.219.23.16 1 6 80 12
25 Sep 2001 16:24:46 Production 206.219.23.16 1 6 27374 3

Next we’ll combine these two reports by asking the database to give us all attack data with an attacker IP of 24.26.198.98, and 209.219.23.16, against “Production” and “Main Office.” We’ll also have it sort by date and time:

Source IP: 24.26.198.98 OR 206.219.23.16
Attack Time Agent Alias Target IP # of Machines
Targeted
IP
Protocol
Target
Port
# of
Probes
25 Sep 2001 16:23:02 Main Office 24.26.198.98 1 6 21 3
25 Sep 2001 16:23:14 Production 24.26.198.98 1 6 21 3
25 Sep 2001 16:23:21 Main Office 24.26.198.98 1 6 137 5
25 Sep 2001 16:23:29 Production 24.26.198.98 1 6 137 5
25 Sep 2001 16:23:45 Main Office 206.219.23.16 1 6 80 12
25 Sep 2001 16:24:01 Production 206.219.23.16 1 6 80 12
25 Sep 2001 16:24:35 Main Office 206.219.23.16 1 6 27374 3
25 Sep 2001 16:24:46 Production 206.219.23.16 1 6 27374 3

This basically, gives us a step-by-step view of how the attack was carried out by the two attackers. This example is very simplistic, but there have been several demonstrated highly complex attacks that have been identified using this analysis method.

Using these reports, it would be apparent to the analyst that a coordinated attack was attempted against both of these IIS servers. Further analysis can be achieved by viewing the actual IDS logs submitted to the central analysis server, and a decision on network vulnerability to attempted attacks can be performed, as per the GIAC standard for incident analysis reports. It would also be advisable to see the aggregated report on the second attackers IP, to see if any other systems had attack attempts from this system, that were not included in this coordinated attack. It has been demonstrated in the past that this system helps the analyst identify large scale, coordinated attacks against large corporate networks, attacks that might otherwise have gone unnoticed due to communications breakdowns between teams and the inability to correlate all the data involved across multiple network segments without a system like this.

Conclusion

The dIDS system gives the analyst a quicker, easier, more efficient method to identify coordinated attacks across multiple network segments, and to trace back the activities of the attackers. The system also, ultimately, saves the corporation whose networks it is deployed on money by reducing the number of Incident Analysts needed, as well as the amount of time required to gather logs from the various IDS systems setup in a large corporate network. By having all of these attack records stored in a single place, it allows the analyst much more flexibility in discovering attack patterns, and other attack issues which may have otherwise gone unnoticed.

As attackers, and attack methods become increasingly complex, the need for a dIDS system in large corporate, and military networks increases drastically. With the increased complexity of these attacks, analysts are leaving themselves open to the problems of communications breakdowns, where one analyst sees a single attack on his segment, and dismisses it as nothing. While several other segments receiving the same attacks in a coordinated manner, their analysts may be dismissing the seriousness of the attack. However, when all the attack data is viewed together, a dramatically different perspective the attack may emerge.

dIDS systems are the next logical level for IDS systems to move to. They are able to be setup with pre-existing architectures and IDS systems, making them even more cost-efficient. It should also be noted that there are currently a few systems in place that fall along the lines of a dIDS. Instead of being based in the corporate environment, focused on in this paper, they are deployed across the entire Internet, which thousands of sensors submitting data to them every day. One such service is SecurityFocus’s ARIS Predictor service, which should be noted due to its large scale demonstration of the use of a dIDS in the reporting of attacks to ISPs, server owners, and their proven ability to identify new worms, and attacks, therefore making the Internet as a whole safer for all.

Nathan Einwechter is currently a Senior Research Scientist with Fate Research Labs, aswell as a System Developer/Incident Analyst with myNetWatchman.Com. While working with myNetWatchman, Nathan assisted in the discovery and analysis of the "W32.Leave.Worm" along with SANS, the FBI, and NIPC. The discovery of which was made possible by analysis of data collected by a dIDS system.



SecurityFocus accepts Infocus article submissions from members of the security community. Articles are published based on outstanding merit and level of technical detail. Full submission guidelines can be found at http://www.securityfocus.com/static/submissions.html.
 
 
 |+| نوشته شده در  سه شنبه بیستم فروردین 1387ساعت 10:55 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام
کلاستر برای تازه کاران

برای آغاز شاید بد نباشد به سایتهای زیر سری بزنید. اطلاعات خوبی برای پیاده سازی یک کلاستر در آنها هست

http://www.mcsr.olemiss.edu/bookshelf/articles/how_to_build_a_cluster.html

همینطور راه‌های ساده‌تری هم هست٬ مثلاً از نرم‌افزارهای آماده‌ای که اینکار را انجام می‌دهند٬ استفاده کنید. به عنوان مثال:

OSCAR http://oscar.sourceforge.net
ROCKS http://www.rocksclusters.org
Scyld http://scyld.com

مثلاً اسکار به کاربر امکان می‌دهد٬ که بدون توجه به تجربه‌اش در محیطهای لینوکس٬ بتواند یک خوشه لینوکس راه‌اندازی کند.

منبع : http://www.blogger.com/profile/09208285748429855857

 

 

 |+| نوشته شده در  چهارشنبه چهاردهم فروردین 1387ساعت 11:41 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام
Red Hat Enterprise MRG و محاسبات موازی و محاسبات روی گرید

شرکت ردهت اقدام به معرفی نسخه‌ی جدیدی از سیستم عامل‌های خود نموده است که در این نسخه٬ محاسبات موازی٬ محاسبات روی گرید٬ و مسائلی از این دست که مورد علاقه محاسباتی کاران است بسیار قابل حصول شده است.

نسخه‌ی بتای این سیستم عامل٬ اکنون قابلِ دانلود است.

به بخشی از توضیحات مربوطه توجه کنید:

Red Hat Enterprise MRG supports the full spectrum of distributed tasks, including:

* High-speed, reliable, or large file messaging
* Parallel & cycle-stealing scheduling
* High Performance Computing (HPC) and High Throughput Computing (HTC)
* Distributed workload management

Red Hat Enterprise MRG can run across multiple platforms but also takes deep advantage of Red Hat Enterprise Linux capabilities like clustering, IO, and virtualization for optimal performance and qualities of service.

مرجع:
http://www.redhat.com/mrg/?intcmp=70160000000HEmC
http://www.redhat.com/mrg/grid

منبع :

http://condmatt.blogspot.com

 

 |+| نوشته شده در  چهارشنبه چهاردهم فروردین 1387ساعت 11:32 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام
Middleware

Middleware در يك سيستم محاسباتی توزيع شده به عنوان لايه نرم‌افزاری تعريف می‌شود كه بين سيستم عامل و برنامه‌ها قرار می‌گيرد و اجرای چند فرايند را بر روی يك يا چند ماشين در شبكه امكان پذير می‌سازد.

Middleware برای انتقال برنامه‌های mainframe به برنامه‌های كلاينت / سرور ضروری است. اين تكنولوژی در سال‌های 1990 تكامل يافت. تكنولوژی‌های Middleware با رشد برنامه‌های مبتنی بر شبكه اهميت پيدا كردند. از سوی ديگر تعداد سيستم‌هايی كه از مجموعه‌ای از ديوايس‌ها تشكيل شده بودند افزايش يافت. هر ديوايس عملكردی را انجام می‌داد كه در شبكه با ساير ديوايس‌ها نظير تلفن‌های هوشمند، كامپيوترهای شخصی، PDA تعامل داشت.

 

عملكردهای Middleware

در هر يك از حالات فوق، برنامه‌ها از نرم‌افزار ميانجی و پروتكل‌های ارتباطی برای انجام عملكردهای زير استفاده می‌كنند:

  • پنهان‌سازی توزيع: توجه به اين واقعيت كه برنامه معمولا از بخش‌های به هم پيوسته‌ای تشكيل شده است كه در مكان‌های توزيع شده اجرا می‌شود.

  • پنهان سازی ناهمگنی اجزای سخت‌افزاری، سيستم‌ عامل‌ها و پروتكل‌های ارتباطی مختلف

  • تهيه رابط استاندارد، يكپارچه و سطح بالا برای توسعه‌گران برنامه‌ها، به گونه‌ای كه برنامه‌ها به سادگی قابل تهيه و استفاده مجدد باشند.

  • تهيه مجموعه سرويس‌هايی برای انجام عملكردهای مختلف همه منظوره.

اين لايه‌های نرم‌افزاری ميانجی، Middleware ناميده می‌شوند.

Middleware با فراهم آوردن محيط برنامه‌نويسی مشترك، پنهان سازی ناهمگونی‌ها، توزيع سخت‌افزار و سيستم عامل زيربنايی و پنهان‌سازی جزييات و برنامه‌نويسی سطح پايين، توسعه برنامه‌ها را آسانتر می‌سازد.

 

برخی‍ از انواع Middleware

Middleware بازتابی: اينگونه Middleware از تكنيك‌های بازتابی برای رسيدن به انعطاف‌پذيری و انطباق با پلاتفرم‌ها استفاده می‌كند.

Middleware رويدادگرا: اين Middleware مفاهيم، طراحی، پياده‌سازی و سرويس‌هايی را در بر می‌گيرد كه از سيستم‌های رويدادگرا پشتيبانی می‌كنند.

Middleware شی‌گرا: Middleware شی‌گرا پارادايم برنامه‌نويسی شی‌گرا را برای سيستم‌های توزيع شده بسط می‌دهد.

Middleware پيام گرا: اين Middleware در لايه‌های پايين مدل شبكه OSI به كار گرفته می‌شود. Middleware‌های مختلف از مدل‌های بربرنامه‌نويسی متفاوت پشتيبانی می‌نمايند. Middleware شی‌گرا متداول‌ترين Middleware است كه در آن برنامه‌ها به صورت آبجكت‌هايی ساخته می‌شوند. CORBA و COM از جمله اين Middleware هستند. Middleware رويدادگرا برای ساخت برنامه‌های توزيع شده غيرمتمركز مناسب است. كنترل فرايند، شبكه‌های خبری اينترنتی از زمره اينگونه Middleware‌ها هستند.

Middleware پيام‌گرا برای برنامه‌هايی كه در آنها پيام‌ها به صورت دائمی ذخيره می‌شوند، مناسب است. برنامه‌های پيام‌رسانی و گردش كار نمونه‌هايی از اينگونه Middleware هستند.

 

طراحی Middleware

Middleware به عنوان واسط بين بخش‌های مختلف برنامه يا بين برنامه‌ها عمل می‌كند. لذا قواعد به كار رفته در معماری نقش اساسی در طراحی Middleware دارند. در اينجا منظور از معماری، معماری كلی سازمان‌ها و الگوهای ارتباطی در زمينه برنامه‌ها و خود Middleware است. هر سيستم Middleware به لايه ارتباطی بستگی دارد. اين لايه امكان عمل بينابينی بخش‌های مختلف را فراهم می‌آورد.

 

چالش‌های فراروی Middleware

هزينه‌ها: هزينه  بكارگيری تكنولوژی Middleware در توسعه سيستم‌ها كاملا به سيستم عامل‌ها و پلاتفرم‌های مورد نياز بستگی دارد. پياده‌سازی Middleware منحصر به فروشنده آن است. لذا به پشتيبانی و نگهداری از جانب فروشنده وابسته است. اين وابستگی تاثير منفی بر انعطاف‌پذيری و قابليت نگهداری سيستم دارد.

پيچيدگی برنامه‌ها: هر چه برنامه‌ها ارتباط درونی بيشتری با هم داشته باشند. تعداد آبجكت‌ها با كاربران و ديوايس‌ها افزايش می‌يابد. اين امر مديريت آبجكت‌ها و پيچيدگی اداره نمودن سيستم را دشوار می‌سازد.

مديريت برنامه‌ها: مديريت برنامه‌های بزرگ، ناهمگون و توزيع شده با مشكلات متعددی از قبيل مسائل امنيتی، نظارتی، وابستگی به چندين زير سيستم، تعريف و پياده سازی خط مشی‌های مديريت منابع روبرو خواهد بود.

 منبع : http://www.pcworldiran.com

 

 |+| نوشته شده در  چهارشنبه چهاردهم فروردین 1387ساعت 11:25 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

جهش اطلاعاتي دنياي رايانه

اين نوشته يک گزارش علمي است از پروژه ملي ژاپن به اسم NAREGI که مخفف National Research Grid Initiative مي باشد که طي يک همايش بين المللي در معرض داوري دانشمندان و متخصصان سراسر دنيا قرار گرفت. نگارنده خود نيز در اين همايش شرکت داشت که جهت اطلاع دوستان محقق داخلي و مسولان مربوطه اين گزارش را تقديم مي نمايد. هدف اصلي پروژه NAREGI اين است که به قدرت محاسباتي پتا(10 به توان 15) فلاپ بر ثانيه دست بيابند. اين ميزان قدرت محاسباتي معادل يک ميليون پينتيوم 4 است. اين پروژه از سال 2003 تا 2007 با بودجه اي از حدود 20 ميليون دلار بر سال تعريف شده است. يعني براي کل پروژه 5 ساله 100 ميليون دلار بودجه پيش بيني شده است. شايد چيزي مثل درآمد نفتي يک روز ما!

قرار است با اين قدرت محاسباتي پتافلاپ بر ثانيه چه کاري بکنند؟ اين طوري که پروفسور H. Nakamura رييس انيستيتوي علوم مولکولي نارا- ژاپن ميگفت اهداف به اين شکل است: 1- به وجود آوردن و نهادينه کردن علم جديدي به اسم علم نانو (نه تکنولوژي نانو) به عنوان يکي از علوم پايه. به نظر نگارنده روحيه متواضع و بي ادعاي ژاپني به سختي مي تواند ادعايي از اين نوع داشته باشد و اگر يک دانشمند ژاپني چنين ادعايي بکند بايد خيلي آن را جدي گرفت! 2- مفهوم GRID را به عنوان ابزار طبيعي اين علم درآورند. GRID يک محيط محاسباتي ناهمگون است که مساله ترجمه کدهاي کامپيوتري بين سيستم عامل‌هاي مختلف را مرتفع خواهد کرد. در حقيقت GRID خود يک سيستم عامل است که توسط ابزارهايي به اسم middleware امکان ارتباط بين کدهاي توسعه يافته تحت سيستم عامل‌هاي مختلف را فراهم مي کند. براي توسعه سيستم عامل GRID و middleware‌هاي مربوطه حدود 300 مهندس کامپيوتر مطابق گفته معاون وزير علوم ژاپن در اين پروژه مشارکت دارند. تاکنون ژاپني‌ها توانسته اند به طور موفقيت آميزي چند برنامه را به عنوان مثالي از عملي بودن اين محيط محاسباتي با استفاده از سيستم GRID حل نمايند: شبيه سازي مولکول‌هاي بزرگ از حدود پروتيين‌ها در خلا با قدرت محاسباتي فعلي به صورت کاملا کوانتومي وجود ندارد. وجود حلال (يعني 10 به توان 23 مولکول آب!) مساله را از اين نيز پيچيده تر ميکند.ولي با استفاده از قدرت فعلي محاسباتي از حدود 17 ترا (10 به توان 12) فلاپ بر ثانيه ژاپني‌ها توانسته اند برخي واکنش‌هاي شيميايي در محلول‌ها و من جمله فرايندهاي حياتي مربوط به پروتيين‌ها را شبيه سازي کنند. اين ميزان قدرت محاسباتي توسط حدود سه هزار رايانه در سرتاسر ژاپن تامين ميشود که توسط شبکه فوق سريع به هم مربوط اند.

هدف غايي اين است که بتوانند قطعات الكترونيك مقياس نانومتر (مشتمل بر حدود يک ميليون الکترون) را بدون ساختن قطعات در آزمايشگاه بر روي سيستم GRID شبيه سازي کنند. البته کاربرد سيستم GRID به شبيه سازي‌هاي کوانتومي و فرايندهاي شيميايي يا کاربردهاي آن در ماده بيولوژيک منحصر نيست. نکته جالب توجه اين است که حدود 40 کمپاني مهم ژاپني نظير هيتاچي و تويوتا نيز در اين پروژه مشارکت دارند. مثلا يکي از کاربردهاي بالقوه اين محيط محاسباتي ميتواند شبيه سازي تصادف خودرو‌ها با جزييات بيشتر و دقيق تر باشد.

نکاتي هم از بحث با برخي دانشمندان اروپايي و آمريکايي که به اين همايش دعوت شده بودند نقل مي‌کنم: پروفسور Sandro Sorella از مرکز SISSA در ايتاليا معتقد است که هرچقدر که تعداد زيادتري کامپيوتر از مراکز مختلف را بتوان تحت تکنولوژي GRID به هم متصل کرد، به همان ميزان نيز متقاضي استفاده از شبکه و اجراي برنامه در شبکه افزايش خواهد يافت که عملا فرقي بين استفاده از GRID يا عدم استفاده از آن وجود ندارد. پروفسور Takami Tohyama از انيستيتوي تحقيقات مواد دانشگاه توهوکو ژاپن در جواب اين سوال من که شما تميز ترين کد قطري سازي دقيق دنيا را در طي 15 سال گذشته توسعه داده ايد حاضريد اجازه دهيد کس ديگري آن سوي دنيا کد شما را کامپيايل کرده و از آن استفاده کند گفت که اين يک روياست! تحقق آن سخت به نظر ميرسد. يک پروفسور روسي الاصل از کانادا هم که متخصص محاسبات بزرگ مقياس است معتقد بود که اگر به فرض به هدف پتافلاپ برسند فقط قدرتشان 1000 برابر قدرت محاسباتي نوعي خوشه‌هاي 512 تايي است که به معناي 10 برابر شدن ابعاد فضايي يک سيستم 3 بعدي است و اشتهاي ما را براي سيستم‌هاي بزرگتر برخواهد انگيخت. چون هنوز اين ميزان كافي نيست.

پروفسور G. Baskaran از انيستيتوي علوم رياضي مدرس هندوستان معتقد است راه حل مسايل پيچيده در فيزيک ماده چگال يا ماده بيولوژيک کامپيوترهاي بزرگ نيست! وقتي يک مساله جديدي با ميزان پيچيدگي جديد فرا روي ما قرار ميگيرد، براي حل آن نياز به ابداع «مفهوم» جديد داريم. به نظر نگارنده نيز اين استاد بزرگوار در حالت کلي فرمايششان متين است. اما به هر صورت کشور ما براي بسياري از مسايل به قدرت محاسباتي از حدود چند ده ترافلاپ بر ثانيه (معادل چند هزار پنتيوم 4) براي برخي پروژه‌هاي ملي نياز دارد.

اگر قرار است که اين ميزان قدرت محاسباتي با چيزي مثل چند ده ميليون دلار حاصل شود براي مملکت ما کار سختي نيست. فقط کافي است که کار را به کاردان بسپارند!! مملکت ما در حال حاضر در شيمي داراي دانشمنداني است که توسط استانداردهاي بين المللي به عنوان دانشمند پر استناد معرفي شده اند. در فيزيک هم تا آنجايي که نگارنده خود به عنوان محقق فيزيک مطلع است دانشمندان قابلي در اين کشور وجود دارند. درعلوم کامپيوتر با اينکه رشته تخصصي بنده نيست ولي بچه‌هايي که قادرند در سطح اسباب بازي (مسابقه فوتبال روبات‌ها) در دنيا اول شوند به وضوح مي توانند در سطوحي جدي تر و کاربردي تر از اين حرف‌ها شانه به شانه دوستان ژاپني ما پيش بروند. در رشته‌هاي ديگر نيز مطمئنا کساني هستند که در صورت اعتماد به آنها قاردند کارهاي مهمي انجام دهند.

نکته آموزنده‌اي که از اين همايش ژاپني مي توان آموخت اين است که روحيه پاسخگويي دانشمندان ژاپني ايجاب ميکند که به ازاي پول 20 ميليون دلار بر سالي که تاکنون استفاده کرده اند، چند تا از برجسته ترين دانشمندان شيمي (به عنوان مثال پر استناد ترين دانشمند شيمي دنيا در اين همايش شرکت داشت)، فيزيک و متخصصان محاسبات بزرگ مقياس را از آمريکا و اروپا دعوت کنند تا در حضور آنها به سنت حسنه «پاسخگويي» بپردازند! هيچ چيز سري هم وجود ندارد! همه به صورت آزاد دعوت شده اند تا نظر دهند. اگر کسي اشکالي در سيستم و رهيافت علماي ژاپني به ذهنش برسد و به آنها تذکر دهد با لبخند مليح ژاپني و ادب و تشکر فراوان آنها مواجه خواهد شد.

 

منبع : http://www.bashgah.net

 

 |+| نوشته شده در  چهارشنبه چهاردهم فروردین 1387ساعت 11:23 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

كامپيوترهاى كوانتومى

ترجمه: شايان شهند

كامپيوترى كه روى ميز تحرير شما جا خوش كرده، براى كاركردن بايد يك مشت صفر و يك را بفهمد و دستكارى كند. همه اطلاعات اعم از حروف و اعداد يا وضعيت مودم و موس شما با مجموعه اى از بيت هاى متشكل از صفرها و يك ها به كامپيوتر داده مى شود. اين بيت هاى اطلاعات، خيلى ساده همان طورى تعريف مى شوند كه فيزيك كلاسيك دنيا را تعريف مى كند؛ سوئيچ هاى الكتريكى مى توانند روشن يا خاموش باشند، اشيا مى توانند اينجا باشند، مى توانند هم نباشند! ولى كامپيوترهاى كوانتومى با طبيعت دودويى هاى فيزيك كلاسيك محدود نمى شوند همه اش به اين بستگى دارد كه حالت بيت هاى كوانتومى يا همان كوبيت ها را چطور ببينيم؛ كوبيت ها ممكن است نشانگر يك صفر يا يك يك، تركيبى از اين دو يا حتى معرف عددى باشند كه حالت آنها را جايى بين صفر و يك تعيين مى كند. با توجه به فيزيك كوانتومى، نمى توان دقيقاً وجود يا عدم وجود يك ذره ريز درون اتمى را مشخص كرد. مى توان به وسيله آمار و احتمال، امكان وجود اين ذره هاى ريز را در مكان و زمان مشخصى تعيين كرد، اما هيچ راهى براى دانستن قطعى اين كه آيا اين ذره آنجا هست يا نه، تا وقتى كه آن را مستقيماً نديده ايم وجود ندارد. البته آنچه كه در كامپيوترهاى كوانتومى با ارزش است همين احتمالات است. اين احتمال بودن يا نبودن است كه نبودن يا بودن كامپيوترهاى كوانتومى را تعيين مى كند.

قدرت زياد پردازنده هاى كنونى هنوز نتوانسته تشنگى بشر به سرعت و ظرفيت محاسبات را برطرف كند. در سال 1947 مهندس آمريكايى «هووارد آيكن» گفت كه فقط 6 كامپيوتر ديجيتال الكترونيكى نياز محاسباتى تمام ايالت متحده را بر طرف مى كند. ديگران هم پيش بينى هاى مشابهى را درباره ميزان قدرت محاسباتى لازم براى برطرف كردن نياز هاى تكنولوژيكى روبه رشد انجام دادند. البته «آيكن» حجم زياد اطلاعاتى كه از تحقيقات علمى ايجاد مى شد را به حساب نياورده بود، گستردگى كامپيوتر ها به عنوان بخشى از زندگى روزمره انسان قرن جديد و ضرورت اينترنت به تنهايى مى تواند نياز بشر به قدرت محاسبات را چند برابر كند. آيا انسان به قدرت مورد نياز خود براى محاسبه و پردازش اطلاعات دست خواهد يافت؟

اگر همان طور كه «قانون مور» مى گويد، تعداد ترانزيستور هاى موجود در يك ريزپردازنده هر هجده ماه دو برابر شود _ و اين روند با همين سرعت ادامه داشته باشد- در سال 2020 يا 2030 مدار هاى روى ريز پرداز نده ها بايد در مقياسى اتمى اندازه گيرى شوند. قدم بعدى كامپيوتر هاى كوانتومى است. كامپيوتر هايى كه با مهار كردن انرژى اتم ها و مولكول ها، از آنها به عنوان حافظه و پردازنده استفاده خواهند كرد. كامپيوتر هاى كوانتومى مى توانند محاسبات را ميليارد ها برابر سريع تر از هر كامپيوتر سيلي-ى ديگرى انجام دهند. دانشمندان پيش از اين كامپيوتر هاى كوانتومى ساده اى كه توانايى انجام محاسبات مشخصى را داشته اند، طراحى كرده اند اما هنوز با يك كامپيوتر كوانتومى كاربردى فاصله زيادى دارند. براى رسيدن به زمان پيدايش ايده كامپيوتر هاى كوانتومى لازم نيست زياد به عقب برگرديم.

تئورى كامپيوتر هاى كوانتومى بيست سال بيشتر ندارد. در سال 1981 فيزيكدان آزمايشگاه Argonne National، «پل بنيوف» اولين تئورى كاربرد نظريه كوانتومى در كامپيوتر ها را منتشر كرد. ايده «بنيوف» ايجاد يك ماشين تورينگ كوانتومى بود. اغلب كامپيوتر هاى ديجيتالى، مثل همين كامپيوتر هايى كه من و شما با آن كار مى كنيم، براساس «نظريه تورينگ» طراحى شده اند. ماشين تورينگ كه در سال 1930 توسط «آلن تورينگ» معرفى شد از يك نوار حافظه با طول نامحدود و يك هد خواندن و نوشتن تشكيل شده بود. اين نوار حافظه به خانه هاى كوچكى تقسيم مى شد كه هر كدام مى توانست حاوى صفر يا يك باشد يا اينكه خالى بماند. دستگاه خواندن و نوشتن با فرمان گرفتن از ماشين مى توانست حركت كند، علائم را بخواند يا تغييرى در آنها ايجاد كند. اين چه ربطى به كامپيوتر هاى كوانتومى دارد؟ در يك ماشين تورينگ كوانتومى اين نوار حافظه و دستگاه خواندن و نوشتن حالت كوانتومى دارد. يعنى اينكه علائم روى نوار مى توانند صفر، يك يا مقدارى بين صفر و يك باشند. به علاوه ماشين تورينگ فقط يك محاسبه در هر لحظه انجام مى دهد، حال آنكه نوع كوانتومى آن مى تواند تعداد زيادى محاسبه را در آن واحد به انجام برساند. كامپيوتر هاى امروزى مثل ماشين تورينگ با دستكارى بيت هايى كه در يكى از دو حالت صفر يا يك هستند كار مى كنند. ولى كامپيوتر هاى كوانتومى به دو حالت محدود نمى شوند. آنها اطلاعات را در قالب كيوبيت ها دريافت مى كنند.

محتويات يك كيوبيت همان طور كه گفته شد صفر، يك، هر دو يا چيزى بين اين دو است. كيوبيت ها در واقع اتم هايى هستند كه با هم كار مى كنند تا يك حافظه يا پردازنده را به وجود آورند. اينكه كامپيوتر هاى كوانتومى مى توانند در يك زمان چندين حالت داشته باشند به آنها اين امكان را مى دهد كه ميليون ها بار سريع تر و قدرتمند تر از ابركامپيوتر هاى فعلى كار كنند. چند حالت پذيرى كيوبيت ها همان دليلى است كه باعث مى شود كامپيوتر هاى كوانتومى ذاتاً از پردازش موازى بهره ببرند. پردازش موازى امكان كار كردن بر روى ميليون ها محاسبه در يك لحظه را به اين كامپيوتر ها مى دهد در حالى كه كامپيوتر شخصى شما فقط يك محاسبه در لحظه انجام مى دهد.

يك كامپيوتر كوانتومى 30 كيوبيتى قدرتى معادل كامپيوترى معمولى با توانايى انجام 10 ترا محاسبه بر روى اعداد اعشارى در يك ثانيه _ ترافلاپس (Teraflops)- دارد. سريع ترين ابركامپيوتر كنونى سرعتى برابر 2 ترافلاپس دارد.

پژوهشگران شركت IBM با استفاده از تكنيك هاى تشديد مغناطيسى هسته اى (NMR) يك كامپيوتر كوانتومى ساخته اند كه اسپين اتم هاى مجزا را اندازه گيرى و دستكارى مى كند. انفجار انرژى امواج راديويى مى تواند با تغيير سطح انرژى يك اتم، پروسه شمارش را شروع كند. پروسه اى كه در تقابل با ساير اتم ها و به صورت كنترل شده اى مى تواند الگويى از شمارش كوانتومى را به وجود آورد. الگويى كه مى تواند به جواب حاصل از كامپيوترهاى معمولى مربوط باشد.

دلايل زيادى براى اين همه تلاش پژوهشگران جهت ساخت و توسعه كامپيوترهاى كوانتومى وجود دارد. اول اينكه اتم ها مى توانند حالت انرژى خود را با سرعت فوق العاده اى تغيير دهند، سرعتى كه نهايتاً باعث افزايش سرعت پردازش اطلاعات كامپيوترها مى شود. ديگر اينكه اگر مسئله اى كه به هر كيوبيت داده مى شود با ذات كامپيوتر كوانتومى سنخيت داشته باشد هر كيوبيت مى تواند جاى يك پردازنده كامل را بگيرد. يعنى اينكه 1000 يون باريوم مى توانند به جاى 1000 پردازنده كامپيوتر كار كنند! كليد استفاده از اين قابليت يافتن گونه مسائلى است كه يك كامپيوتر كوانتومى مى تواند حل كند. خيلى بعيد است كه روزى شما شاهد حضور يك كامپيوتر كوانتومى روى ميز كارتان باشيد. چرا كه اين كامپيوترها براى انجام كارهايى چون پردازش متون يا چك كردن اى ميل طراحى نشده اند. از طرفى ديگر رمزگشايى و رمزگذارى در ابعاد وسيع براى كامپيوترهاى كوانتومى ايده آل است. و كاركردن با پايگاه هاى داده بزرگ جزء بخش هايى است كه مسلماً كامپيوترهاى كوانتومى حرف اول را در آن خواهند زد.

كامپيوتر هاى كوانتومى مى توانند روزى جاى كامپيوتر هاى سيلي-ى را بگيرند همان طور كه ترانزيستور ها حباب هاى خلأ را از ميدان به در كردند. البته امروزه تكنولوژى مورد نياز براى اين كامپيوتر ها چندان پيشرفت نكرده است. اغلب تحقيقات در باب كامپيوتر هاى كوانتومى هنوز در حد تئورى اند. پيشرفته ترين كامپيوتر كوانتومى حاضر هنوز از پس كار كردن با بيش از 7 كيوبيت برنيامده است. يعنى آنها هنوز در مرحله 2=1+1 هستند. علاوه بر اين، آنچه كه كامپيوتر هاى معمولى امروزى به زحمت و به كندى انجام مى دهند، كامپيوتر هاى كوانتومى، به سرعت و در كسرى از ثانيه انجام خواهند داد.

كامپيوتر هاى كوانتومى مى توانند فاكتوريل اعداد بزرگ را در كسرى از ثانيه محاسبه كنند. از آنها مى توان براى جست وجو در پايگاه هاى داده بزرگ و رمز گذارى و رمز گشايى استفاده كرد. اگر امروز يكى از آنها وجود داشت ديگر هيچ، اطلاعاتى بر روى اينترنت امن نبود. سيستم هاى ساده كد گذارى امروز در برابر سيستم هاى پيچيده كامپيوتر هاى كوانتومى فردا حرفى براى گفتن نخواهند داشت.

وجود اينچنين كاربردهاى وسيع و مهمى است كه دانشمندان را به كار بر روى كامپيوترهاى كوانتومى مشتاق كرده است. اگرچه دانشمندان و مهندسان تعدادى كامپيوتر كوانتومى كوچك ساخته اند ولى در راه توليد و توسعه كامپيوترهاى كوانتومى تجارى كارا مشكلات مهمى وجود دارد. مهمترين آنها حفظ يك يون در حالت پايدار، هنگام مشاهده سطح انرژى و جهت اسپين آن است. در حال حاضر يون ها با استفاده از ليزر در دمايى نزديك به صفر مطلق نگهدارى مى شوند. اين كار را بعد از جداسازى يك اتم از گروهى و قرار دادن آن در جاى خودش انجام مى دهند. تا به حال گونه هاى ارائه شده از كامپيوترهاى كوانتومى چيزى بين دو تا چهار اتم داشته اند. تكنيك هاى NMR كه به وسيله IBM استفاده شده است راهى براى تحقيق درباره تاثير حالت يون ها بدون مشاهده مستقيم آنها ارائه مى دهد. مشاهده مستقيم يون ها منجر به از بين رفتن احتمالات و لفظ «هردو يا چيزى بين صفر و يك» خواهد شد، اين يعنى نابود كردن بنياد كامپيوترهاى كوانتومى.

اما كامپيوتر هاى كوانتومى هنوز راه زيادى براى پيمودن و پيشرفت دارند. آنها براى مواجه شدن با مشكلات دنياى واقعى بايد حداقل چندين جين كيوبيت داشته باشند.

از كامپيوتر هاى كوانتومى مى توان براى رمز گذارى و رمز گشايى استفاده كرد اگر امروز يكى از آنها وجود داشت ديگر هيچ اطلاعاتى بر روى اينترنت امن نبود.

منبع: http://www.hupaa.com/Data/P00269.php

 

 |+| نوشته شده در  یکشنبه یازدهم فروردین 1387ساعت 12:37 بعد از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

MultiThreading چیست؟

مقدمه -
گاهی اوقات ممکن است که شما بخواهید برنامه شما دو یا چند عمل را به طور همزمان انجام دهد و یا اینکه نیاز به انجام عملیاتی که مدت زمان زیادی به طول می انجامد و یا زمان انجام آن معلوم نیست ، باشد ، بدون اینکه برنامه شما از دسترس کاربر خارج شود و به اصطلاح برنامه شما تا پایان یافتن عملیات قفل کند و همچنین کاربر بتواند عملیات را متوقف/معلق/شروع دوباره نماید . در چنین موقعیتی نیاز به MultiThreading حس میشود . به فرض مثال کد زیر را در نظر بگیرید :

کد:
For i As Integer = 0 To 10000000
            For i2 As Integer = 0 To 100
                'Do Nothing
            Next
        Next



هنگامی که این عملیات شروع میشود ، کاربر توانایی کار با برنامه تا پایان یافتن آن را نخواهد داشت .

Thread چیست؟

Thread نامی برای جریان اجرای یک عملیات خاص میباشد و هنگامی که برنامه شما دارای چند Thread میباشد بدان معناست که قسمت های مختلفی از کد برنامه شما به طور همزمان در حال اجرا شدن میباشند . در حقیقت کامپیوتر زمان پردازش یک عملیات را به قسمت(slice) های مختلفی تقسیم میکند و هنگامی که شما یک Thread جدید را آغاز میکنید کامپیوتر قسمتی از زمان را به آن اختصاص میدهد . لازم به ذکر است که برنامه شما از ابتدا دارای یک Thread اصلی (Main Thread) برای اجرا کد مربوط به آن میباشد .

کار خود با Thread ها را آغاز مینماییم :
میخواهیم برنامه ای بنویسیم که تا یک عدد معین عملیات شمارش را انجام دهد .
1 – یک پروزه Windows Apploication به نام MutiThreading Sample ایجاد نمایید .
2 – یک Button به نام btnStart و یک TextBox به نام txtMAX به فرم اضافه نمایید .
3 – یک کلاس به نام clsCounter به پروژه اضافه کرده و کد زیر را در داخل آن قرارهید :

کد:
Public Class clsCounter
    Public MAX As Integer
    Public Event CountingFinished(ByVal Number As Integer)
    Sub StartCounting()
        Dim intTotal As Integer
        For i As Integer = 0 To MAX
            intTotal += 1
        Next
        RaiseEvent CountingFinished(intTotal)
    End Sub
End Class


توضیحات در مورد کد فوق :
• وظیفه این کلاس شمردن از 1 تا مقدار MAX میباشد .
• رویدادی با نام CountingFinished تعریف کردیم که هنگامی که عملیات شمارش به پایان برسد اتفاق می افتد .
• متد StartCounting از 1 تا مقدار intMax را شماره کرده و در هر بار اجرای حلقه یک واحد به مقدار متغیر intTotal اضافه میشود که در نهایت مساوی با مقدار MAXخواهد بود .
• پس از پایان شمارش رویداد CountingFinished را همراه با پاس کردن متغیر intTotal به آن اجرا مینماییم .

حال ما باید در هنگامی که دکمه کلیک میشود یک Thread جدید ایجاد کرده و سپس متد StartCounting کلاس clsCounter را اجرا کرده و رخدادن رویداد CountingFinished را کنترل نماییم . در زمانی که عملیات شمارش انجام میشود ما میتوانیم رابط کاربری را کنترل کرده و کاربر توانایی کار با برنامه را دارد .

حال کد زیر را به پروژه خود اضافه نمایید :

کد:
Sub CountingFinishedEventHandler(ByVal N As Integer)
        System.Windows.Forms.MessageBox.Show("Counting Finished!")
    End Sub
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnStart.Click
        Dim CounterClass As New clsCounter
        Dim CountingThread As New Threading.Thread(AddressOf CounterClass.StartCounting)
        CounterClass.MAX = Val(txtMax.Text)
        AddHandler CounterClass.CountingFinished, AddressOf CountingFinishedEventHandler
        CountingThread.Start()
    End Sub



توضیحات در مورد کد فوق :
•ابتدا یک پروسیجر برای کتترل رویداد CountingFinished مربوط به کلاس Counter ایجاد مینماییم . هنگامی که رویداد اتفاق بیافتد(عملیات شمارش به پایان برسد) ، پیغامی مبنی بر پایان یافتن عملیات به کاربر نشان داده خواهد شد .
• در رویداد Click شی ء btnStart ، ابتدا یک نمونه از کلاس CounterClass ایجاد مینماییم .
• سپس برای ایجاد شی ء Thread ، آدرس متذ clsCounter.StartCounting را به سازنده کلاس Thread پاس مینماییم به طوری که متد clsCounter.StartCounting را بعد از آوردن کلمه کلیدی addressof ، می آوریم .
• بعد ، توسط کلمه کلیدی Addhandle ، کنترل کننده رویداد که CountingFinishedEventHandler نام دارد را به رویداد clsCounter.CountingFinished متصل مینماییم .
• در آخر نیز توسط متد Start مربوط به شیء CountingThread ، عملیات را آغاز مینماییم .

برخی متدهای دیگر مربوط به شی ء Thread :
Suspend و Resume : در حالی که یک Thread در حال اجراست ، توسط متد Suspend میتوانید آن را معلق کنید که منجر به متوقف شدن آن تا زمانی که متد Resume اجرا شود ، خواهد گردید .
Abort : Thread را متوقف میکند .
Sleep : توسط این متد میتوانید اجرای Thread را برای پاره ای از زمان (برحسب میلی ثانیه) به حالت تعلیق دربیاورید .


اولویت بندی Thread ها :
شما کنترل بیشتری بر روی Threadها دارید و میتوانید مقدار زمانی که هر Thread نسبت به دیگر Thread ها دریافت میکند را از طریق خاصیت Priority تنظیم نمایید . این خاصیت توسط یکی از ثابت های شمارشی زیر که عضوی از ThreadPriority میباشد تنظیم میشود :
ThreadPriority.AboveNormal : اولویت بالاتری به Thread میدهد .
ThreadPriority.LowerPriority : اولویت پایین تری به Thread میدهد .
ThreadPriority.HighestPriority : بالاترین اولویت را به Thread میدهد .
ThreadPriority.LowestPriority : پایین ترین اولویت را به Thread میدهد .
ThreadPriority.Normal : تولویت نرمال را به Thread میدهد .

پیدا کردن وضعیت Thread :
وضعیت یک Thread را میتوانیم به وسیله خاصیت ThreadState به دست بیاوریم که به وسیله یکی از ثابتهای شمارشی System.Threading.ThreadState معین میگردد .
System.Threading.ThreadState.Initialized : بیان میکند که Thread مقداردهی اولیه شده اما هنوز شروع نگردیده است .>System.Threading.ThreadState.Ready : Thread آماده است .
System.Threading.ThreadState.Running : بیان میکند که Thread در حال اجرا است .
System.Threading.ThreadState.Standbye : بیان میکند که Thread در حالت آماده به کاراست .
System.Threading.ThreadState.Initialized :بیان میکند که Thread به پایان رسیده است .
System.Threading.ThreadState.Transition : بیان میکند که Thread بین دو وضعیت بوده و در حالت انتقال از وضعیتی به وضعیت دیگر است .
System.Threading.ThreadState.Unknown : بیا میکند که وضعیت Thread معلوم نیست .
System.Threading.ThreadState.Wait : بیان میکند که Thread در حالت انتظار است .

مثال

کد:
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim Thread1 As New Threading.Thread(AddressOf test)
        Thread1.Start()

        Dim Thread2 As New Threading.Thread(AddressOf test)
        Thread2.Start()
    End Sub
    Public Sub test()
        MsgBox("test")
    End Sub
هر دو messageBox رو با هم می بینیم. اما اگر کد زیر رو بنویسیم:

کد:
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        test()
        test()

    End Sub
    Public Sub test()
        MsgBox("test")
    End Sub
ابتدا messageBox اول و پس از ok کردن دومی را خواهیم دید
 
 
 
 |+| نوشته شده در  یکشنبه یازدهم فروردین 1387ساعت 12:33 بعد از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

GTCMPS94 (سيستم هاي كنترل توزيع شده DCS)

سیستمی الکترونیکی بوده که صرفاً به منظور کنترل نظارت و حفاظت توربوژنراتور V94.2 به کار گرفته شده است . سیستم GTCMPS94 یک سیستم کنترل توزیع شده (DCS) میکروپروسسوری میباشد که در این تحقیق سعی شده است قسمتهای مختلف آن بررسی گردد .
 

مقدمه

يكي از مقوله هايي كه امروزه در زمينه اتوماسيون مورد توجه قرار گرفته است ، مسئله ايجاد شبكه كامپيوتري براي كنترل فرآيندهاي صنعتي است ، يكي از اين سيستمها، سيستم كنترل توزيع شدهDCS ميباشد .

پيشرفت سريع كامپيوتر و كاربرد آنها در سيستم هاي كنترل ، در چند سال اخير افزايش حيرت انگيزي كرده است ، اين پيشرفت سريع در كشور ما نيز با سرعت كمتري نفوذ كرده و بسياري از كارخانجات كشور مجهز به سيستم هاي كنترل كامپيوتري گسترده و نيمه گسترده شده اند.صنعت توليد برق بي شك يكي از پيشگامان اين عرصه مي باشد .

تحقيق زير مطالب جمع آوري شده و انتخاب شده اي از مدرك Elsag Bailey process automation و جزوات I&C Maintenance و مدارك بهره برداري ابزار دقيق توربين گاز V94 و مدارك گسسته شركت Ansaldo و تجربيات عملي ميباشد .

فصل 1 -  GTCMPS94

سيستمي الكترونيكي بوده كه صرفاً به منظور كنترل نظارت و حفاظت توربوژنراتور V94.2 به كار گرفته شده است . سيستم GTCMPS94 يك سيستم كنترل توزيع شده (DCS) ميكروپروسسوري ميباشد كه در اين تحقيق سعي شده است قسمتهاي مختلف آن بررسي گردد .

تمامي تجهيزات سخت افزاري اين سيستم در تابلوهاي اتاق كنترل واحد نصب گرديده اند .

GTCMPS94 در پردازش ، مدارهاي واسط ، ارتباطات و منبع تغذيه داراي افزونگي ( Redundant ) مي باشد .

GTCMPS94 به منظور كنترل تمام اتوماتيك مجموعه توربين گاز و ژنراتور و انجام وظايف اصلي زير طراحي شده است :

- راه اندازي ، بهره برداري ، و Shut-down خودكار

- كنترل راه انداز (Drive Control)

- كنترل سوخت

- اتصال واحد به شبكه (Synchronization )

- نظارت (Monitoring)

- حفاظت توربوژنراتور

ساختار شبكه استفاده شده براي اين سيستم بر اساس استاندارد TCP/IP مي باشد

 

پيكر بندي استاندارد سيستم

ساختار GTCMPS94 شامل :

• يك مجموع از تابلوها ، شامل بردهاي ميكروپروسسوري ، افزونگي منبع تغذيه ، بردهاي I/O و اتصالات

• ايستگاه واسط اپراتوري (Operator Interface Unit ياOIU ) نوع Stand-alone براي اتاق كنترل واحد شامل مونيتور ، صفحه كليد ، موس و چاپگر آلارم ( براي هر واحد )

• ايستگاه واسط اپراتوري نوع روميزي (Desk Top) براي اتاق كنترل مركزي شامل مونيتور ، صفحه كليد موس وچاپگر آلارم ( براي هر واحد )

• يك كنسول مهندس شيفت براي هر نيروگاه بايد در نظر گرفته شود . كنسول سرمهندس شيفت امكان هر گونه دسترسي به سيستم را در اختيار بهره بردار قرار مي دهد . اين كنسول بايد توانايي كنترل و نظارت بر هر يك از توربين هاي گازي مدول را داشته باشد . Refresh Time اين كامپيوتر براي صفحات تصويري حداكثر 2 ثانيه است .

• يك ايستگاه كاري مهندسي به عنوان يك دستگاه ويژه تعميرات كه مي تواند براي مجموعه نيروگاه در نظر گرفته شود اين كامپيوتر در يك اتاق مخصوص ( جنب اتاق فرمان اصلي نيروگاه ) قرار مي گيرد و مي تواند دسترسي به همه مدول هاي متصل به سيستم را با امكانات ويژه خود فراهم سازد . اين امكانات شامل سفارشي كردن سيستم ، اصلاح اطلاعات پيكر بندي ، ايجاد صفحات جدد تصويري يا اصلاح صفحات قديمي و انجام هر گونه برنامه هاي عيب يابي و تشخيص خطا مي باشد.

• SER براي 128 سيگنال با دقت زماني 1 msec .

• تابلوي توزيع انرژي

• تابلوي ابزار دقيق نظارتي توربين

GTCMPS94 از طريق شاهراه اطلاعاتي اجازه اتصال و توسعه سيستم به ايستگاه واسط اپراتور راه دور و يا سيستم هاي خارجي مرتبط با ساير واحدها را مي دهد .

ساختار سيستم بايستي بر مبناي استفاده از ريز پردازنده هاي 32 بيتي با سطح افزونگي تشريح شده در زير باشد . همچنين سيستم بايد توانايي مديريت 1800 ورودي / خروجي با 20% ظرفيت يدكي ، كه 10% آن نصب و تست شده است داشته باشد .

 

براي اطمينان از صحت عمل سيستم كنترل ، GTCMPS94 داراي افزونگي در سطوح زير مي باشد .

• پردازش ها

• مدارهاي واسط

• ارتباطات

• منبع تغذيه

 

كليه وظايف كنترل ، حفاظت و نظارت در كارت هاي پردازش كننده (MFP) با افزونگي دو تايي اجرا مي گردند پيكر بندي سخت افزاري به صورت Hot-Stanby مي باشد .

در اين جفت پردازشگر ، يكي از پردازشگرها به صورت فعال و ديگري به صورت پشتيبان عمل مي كند . درحالت عادي MFP اوليه كار عادي خود را انجام داده و MFP ديگر به صورت Hot-Stanby مي باشد به اين معنا كه چنانچه MPF اوليه دچار خرابي شود ،MFP دوم بدون هيچگونه اختلاف در روند كنترل اتوماتيك وارد عمل شده و كنترل سيستم را به عهده مي گيرد ، در چنين مواردي يك آلارم در سيستم فعال مي گردد . در اين حال MFP خراب را در حين كار واحد ، بدون هيچ مشكلي مي توان تعويض نمود .

منبع : http://www.autoir.com/page.php?id=97

 

 |+| نوشته شده در  یکشنبه یازدهم فروردین 1387ساعت 12:28 بعد از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

چرا دو پردازنده بهتر از یك پردازنده است...

برای بالا بردن قدرت كامپیوتر، مردم به لطایفالحیل زیادی متوسل میشوند، كه یكی از متداولترین آنها، دو قلو كردن، یا سه قلو كردن، یا حتا چهار قلو كردن پردازندههاست.

 
برای بالا بردن قدرت كامپیوتر، مردم به لطایفالحیل زیادی متوسل میشوند، كه یكی از متداولترین آنها، دو قلو كردن، یا سه قلو كردن، یا حتا چهار قلو كردن پردازندههاست. پردازنده با حداكثر سرعت خود كار میكند تا عملیاتی را انجام دهد كه از نان شب هم برای كامپیوترتان واجبتر است. پردازنده به پردازش دستورالعملهایی میپردازد كه برای اعمالی مانند باز كردن برنامهها، كپی نمودن فایلها، و تمام آن زرق و برقهایی كه روی نمایشگرتان بالا و پایین میروند، به كار میروند.
پردازندهها به دو منبع منحصر به فرد از حافظه متوسل می شوند تا در حین پردازشهای دیگر خود، به دادههای مورد نظرشان نیز دست پیدا كنند. اوّلین منبع حافظه، ثبّات پردازنده است. ثبّات از نظر پردازنده همان نقشی را دارد كه حافظه برای كل كامپیوتر. اطلاعاتی كه پردازنده در حال كار با آنهاست، در ثبّات نگهداری میشود.
منبع دوّم حافظه به «كاشه» مشهور است؛ كه میتوان آن را نوعی زاغهی مهمات در نظر گرفت. در حالت كلی دو كاشه وجود دارد كه پردازندهها میتوانند به سراغشان بروند، و در حالی كه هیچ كدام از آنها در بازیابی دادهها به سرعت ثبّات نیستند، هر دوی آنها از سرعت نسبتاً بیشتری نسبت به حافظهی متعارف كامپیوتر یا سختدیسك برخوردارند (و حتا منابع دیگر حافظه كه پردازنده میتواند به آنها دست پیدا كند)...
حال كه پردازندهی شما مسؤولیت این همه كار را در كامپیوترتان برعهده دارد، آیا عاقلانهتر نیست كه بیش از یكی از آنها را در كامپیوتر خود نصب كنید؟ خوب، هم بله و هم خیر. داشتن بیش از یك پردازنده- یا چند پردازنده- میتواند سرعتتان را افزایشدهد. این امر به نوبهی خود، هزینههای شما را بالاتر میبرد.
بنابراین كسی كه میخواهد به فكر یك كامپیوتر چند پردازندهای بیفتد، باید قبل از آن تصمیم گرفته باشد كه میخواهد از كامپیوترش چه استفادهای ببرد.
اكثر مردم كه از كامپیوترشان به عنوان یك كامپیوتر شخصی- با تاكید با شخصیبودن آن- استفاده میكنند، و امورات روزمرهی خود را با آن میگذرانند. هیچ نیازی به پردازندههای چندقلو ندارند.
پردازندههای چندتایی بیشتر در محیطهایی به كار میروند كه پای بانكهای دادهای بسیار حجیم و سنگین در وسط باشد، یا جایی كه با گرافیكهای پیچیده سروكار دارند، یا در مراكزی كه به ترافیك شدید اینترنت احتیاج داشته باشند. منتها، هیچ ضرری ندارد اگر با چند مفهوم اولیهی پردازندههای چندتایی آشنا شوید تا در مورد تعدد پردازندههای خود و گزینههایی كه پیش روی دارید، بهتر تصمیم بگیرید.
برای ورو به این بحث، اوّل از همه باید بدانید كه بیش از یك روش برای استفاده از پردازندههای چند قلو وجود دارد. روش «پردازشهای چندتایی متقارن
۱» منوط به دو یا چند پردازنده است كه در سیستم نصب میشوند و از یك حافظه و یك سختدیسك واحد مشتركاً استفاده میكنند. در روش متقارن، عملیات پردازش واحد به طور مساوی بین پردازندههای مختلف تقسیم میگردد. روش دیگر، روش «پردازشهای چندتایی غیرمتقارن۲» است كه در آن نیز منابع حافظه و سیستم در بین بیش از یك پردازنده توزیع میگردد.
تنها تفاوتی كه در اینجا وجود دارد آن است كه پردازندههای مختلف به عملیات مختلفی مشغول میشوند. در روش غیر متقارن، یك پردازنده متصدی برنامههای كاربردی میشود، در حالی كه پردازندهی دیگر، عملیات مربوط به خود سیستم عامل را به اجرا در میآورد.
«پردازش موازی انبوه
۳» با منابع مشترك هیچ مناسبتی ندارد. در روش پردازش انبوه، هر پردازندهای از حافظهی مختص به خود و خط حامل خاص خود استفاده میكند. این به آن معنی است كه هیچ یك از پردازندهها مجبور نیستند برای دسترسی به خط حامل سیستم یا حافظه منتظر بمانند، در نتیجه تمام پردازندهها با حداكثر سرعت و توان خود كار میكنند.
روی آوردن به پردازندههای چندتایی
روی آوردن به یك سیستم چند پردازندهای، به چیزی بیش از خرید یك پردازندهی دوم بستگی دارد. درواقع شما باید برد مادر مبتنی بر پردازش متقارن خود را با تراشهی خاصی كه بتواند عملكردهای متعدد تمام پردازندههای موجود را در آن واحد اداره نماید، تجهیز نمایید. در عینحال، پردازندههایی كه میخواهید آنها را به كار ببرید، نیز باید قابلیت پردازش متقارن را داشته باشند.
چند مورد از توابع پیچیدهای كه از الزامات پردازندههای چندتایی است، ارزش بررسی كردن را دارند. برای آنكه دو پردازندهی موجود در سیستم از یك دیگر جلوتر نیفتند و دادههایی را تولید نكنند كه عمرشان به سر رسیده است، چندپردازشی به چیزی متكی میشود موسوم به «همبستگی كاشهها
۴».
در اینجا یك پردازنده وارد حافظهی كاشهكردهی خود میشود تا تكهای از اطلاعات مورد نیازش را بیرون بكشد، و پردازندهی دیگر -بدون اطلاع آن یكی پردازنده- بررسی میكند كه آیا آن فقرهی خاص در آخرین لحظه به روز در آمده است یا خیر، كه اگر آن فقره به روز درآمده باشد، آخرین و جدیدترین دادهها را تامینسازد. این همبستگی كاشهها مانع از آن میشود كه دادهها به هم ریخته گردند؛ آن هم با كاركردن كم و بیش جداگانهی یك یا چند پردازنده روی یك عملیات واحد.
ویژگی دیگری كه موجب بهتر كاركردن چند پردازشی میشود، به «نوبتكاری خط حامل
۵» مربوط میشود. به منظور دست یافتن به حافظهای كه در عمق بیشتری از كاشهی پردازنده قرار دارد- مثلاً حافظهی متعارف یا سختدیسك كامپیوتر- پردازنده باید از روی چیزی حركت كند كه به آن خط حامل سیستم میگویند. هنگامی كه بیش از یك پردازنده در حال انجام وظیفه باشد، ممكن است در مورد اینكه چه پردازندهای باید اوّل سوار این خط شود، دعوایی به راه بیفتد و برخوردی رخ دهد.
نوبت كاری خط حامل به هر یك از پینهای پردازندهها، یك ولتاژ متفاوت اختصاص میدهد تا از روی آن معلوم شود كه چه پردازندهای فعال و چه پردازندهای بیكار است.
پردازندهی فعال حق تقدم سوار شدن روی خط حامل را پیدا میكند. همین تغییر وضعیت فعال و غیر فعال كه تصادفاً بین هر دو پردازنده رخ میدهد، باعث میشود كه هیچكس دست و پایش را گم نكند و در این شلوغی سرگیجه نگیرد!
در یك جمله، قابلیت پردازندههای چندتایی را همه دوست دارند، امّا به درد كامپیوتركاران خانگی نمیخورد. دوبرابر كردنِ تعداد پردازندهها الزاماً به معنی دوبرابر شدنِ سرعت كامپیوترتان نیست، مگر آنكه همیشه از نرمافزارهای خاصی استفاده كنید كه حداكثر استفاده را از پردازندههای دو قلو ببرند.
در مورد بیشتر كاربران خانگی، این مورد وجود ندارد. برای آنها، و با توجه به هزینهی تمام ملزومات مورد نیاز بهتر است به كلاس ماشیننویسی بروید تا سرعت ماشین كردنتان افزایش یابد و به جای آنكه پول بیزبان را خرج این قبیل زرق و برقهای اضافی بكنید، مهارت و تسلطتان را در استفاده از كامپیوترتان بیشتر نمایید.
 

Symmetric MultiProcessing (SMP)
Asymmetric MultiProcessing (AMP)
Massively Parallel Processing (MPP)
Cache Coherency
Bus arbitraion

 

منبع:

ماهنامه کامپیوتر
 
 
 |+| نوشته شده در  چهارشنبه هفتم فروردین 1387ساعت 8:11 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

Code Mobility and Session State

Code mobility as provided for by Request Based Distributed Computing RBDC (see backgrounder) is key for delivering On-Demand computing, Distributed Computing (e.g. SETI@home) and Rich Internet Applications.

RBDC enables the mobility of code that gets its input from http sources (url, request body, cookie, and passwordless GETs). This post looks into whether session state can be made mobile as well.

How can code that relies on session state be made mobile?

In a typical scenario, http servers associate session state with client request streams through the use of a server-unique session-id that is preserved between accesses via a cookie. An example of this is PHP’s handling of sessions. Under this scheme the server held session state prevents the code being mobile. The code is not mobile because the session state is only available in the server that generated the client’s requested resource.

Using RBDC, code that relies on session state can be made securely mobile. Here is one way.

[[Since writing this post, I have realised that the mechanism described here is the same mechanism that makes Google Reader Public Pages both globally available and private.]]

Firstly, the server stores the session state using a globally-unique-id (GUID) insead of server-unique-id as the key. The key is preserved between requests in the client cookie as is now done. Then the server makes the session state publically available at a well known URL. For example, an xml serialised version of the state could be GET and POSTable at a URL like https://www.myserver.com/sessionstate. The GUID used is sufficiently long to prevent guessing and therefore session state will be securely and globally available.

With session state stored in such a secure and globally available fashion, code that requires session state may also be mobile.

منبع : http://www.davidpratten.com

 

 |+| نوشته شده در  شنبه سوم فروردین 1387ساعت 11:53 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

اعمال هم زمان در پایتون ( بخش دوم )

مفسر پایتون به شکل بسیار حرفه ای و پیچیده ای در زبان برنامه نویسی C پیاده سازی شده به طوری که خیلی از برنامه نویس های C هم نمی تونن به راحتی از کدهاش سر در بیارن. و خب مسلما با این شرایط میشه گفت جز تیم اصلی برنامه نویسی پایتون — که در صدر اون ها ون روسوم قرار داره – کسی نیست که بخواد به تمام جوانب طراحی این مفسر آشنا باشه. و تا حدودی هم نیازی به این آشنایی حس نمیشه چون در پایتون اصولا لازم نیست چیزی در مفسر تغییر کنه و بیشتر لازم داریم که چیزی به اون اضافه کنیم که این کار هم چندان سخت نیست.اما یه مبحث در ساختار طراحی پایتون بسیار شناخته شده است. مبحثی که همه می دونن چه مزایایی داره و چه خدمتی به مفسر پایتون کرده و از جهتی هم همه ازش متنفرن و همگی خواستار کنار گذاشتن این ساختار از مفسر پایتون شدن. این ساختار چیزی نیست جز ساختار معروف GIL یا Global Interpreter Lock که میشه تو فارسی اونو به شکل “قفل سراسری مفسر” ترجمه کرد.اما این GIL چیه و دقیقا چی کار میکنه. مسلما در طراحی مفسر پایتون برای بالا بردن سرعت و امکان انجام کارهای هم زمان از تکنیک چند نخی استفاده شده. در ضمن شما می تونید تکنیک چند نخی رو در برنامه هایی که توسط مفسر پایتون اجرا می شن هم به کار ببرید. اما استفاده از چند نخی همونطور که مزایایی داره می تونه خطراتی هم داشته باشه که بزرگترین اونها دخالت نخ های مختلف تو کار همدیگست.این وضعیت زمانی اتفاق می افته که یک نخ به طور ناخواسته به حریم نخ های دیگه وارد بشه که این وضعیت تو زبان هایی مثل C یا C++ و بقیه زبان های برنامه نویسی خیلی اتفاق می افته. این کار در سطح مفسر میتونه حرکت اجرایی مفسر رو کاملا مختل کنه و در سطح برنامه می تونه باعث به وجود اومدن خطاهای زمان اجرا بشه.از اون جایی که پایتون روی ساده تر کردن کارها تاکید داره, طراحان مفسر تصمیم گرفتن از ساختار GIL استفاده کنن. به این صورت که شما می توانید نخ های زیادی ایجاد کنید ولی در هر زمان فقط اجازه ی استفاده از یکی از اون ها رو دارید. وقتی برنامه از تکنیک چند نخی استفاده میکنه, GIL بعد از اینکه مقداری از کدهای هر نخ رو اجرا کرد, کار این نخ رو متوقف میکنه و وضعیت نخ رو در حافظه ذخیره میکنه, و بعد از این کار شروع به اجرای کدهای نخ بعدی میکنه و این کارو تا زمانی انجام میده که تمام کدهای موجود در نخ ها اجرا بشن و از اونجایی که در هر لحظه فقط یک نخ فعال میشه امکان تداخل نخ ها تو کار همدیگه خیلی کم تر میشه. GIL در سرتاسر مفسر پایتون پیاده سازی شده و علاوه بر اینکه روی کدهای شما تاثیر می ذاره, حرکات سطح پایین مفسر رو هم در بر میگیره و از همین جهت هستش که توسعه ی مفسر با استفاده از C اینقدر ساده هستش وگرنه شما مجبور بودید با مشکلات مربوط به چند نخی به طور مستقیم دست و پنجه نرم کنید. خب پس تا اینجای کار GIL میتونه :

استفاده از تکنیک چند نخی رو ساده تر کنه.
استفاده از تکنیک چند نخی رو امن تر کنه.
تغییر در مفسر رو راحت تر کنه.
توسعه ی مفسر رو راحت تر ساده تر کنه.

اما از طرفی هم :

نمی ذاره چند نخ به طور هم زمان اجرا بشن و فقط می تونه همزمانی رو شبیه سازی کنه.
نمی تونه از پردازنده ها و یا هسته های اضافی CPU استفاده کنه و همه ی کارها رو روی یه هسته انجام میده.

یه نکته ای که قابل ذکر هستش اینه که مفسر به کدهای خارجی کاری نداره. مثلا اگه تولکیت Qt از چند نخی استفاده می کنه, استفاده از اون در پایتون باعث تحت پوشش قرار گرفتن کار Qt توسط GIL نمیشه و اون خیلی راحت می تونه به طور واقعی از چند نخی استفاده کنه. البته موقع نوشتن رابط پایتون برای همچین برنامه هایی باید به یه سری نکاتی هم توجه بشه تا باعث به وجود اومدن مشکل نشه.

کاربران پایتون خواستار برداشته شدن این ساختار از مفسر هستن تا بتونن به طور واقعی از چند نخی استفاده کنن و همچنین از منابع اضافی مثل CPU های چند هسته ای هم بهره ببرن. ولی به دلایلی این کار به همین راحتی ها قابل انجام نیست:

GIL در سرتاسر مفسر استفاده شده و حذف اون اصلا ساده نیست.
حذف GIL می تونه باعث بشه مفسر یه بار دیگه از نو نوشته بشه.
از این به بعد دیگه باید مثل C++ خودتون مسئول مدیریت نخ هاتون باشید.
تمام توسعه های پایتون باید از اول نوشته بشن چون همشون بر پایه GIL هستن.
امکان داره مقدار زیادی سرعت رو از دست بدید!

این مورد آخر یک بار زمانی که پایتون در نسخه ی 1.5 قرار داشت آزمایش شد. یعنی GIL از مفسر حذف شد و باعث شد سرعت اجرای برنامه ای با یک نخ در پایتون به نصف سرعت قبلی برسه و چون خیلی از برنامه های پایتون از چند نخی استفاده نمی کنن این کار زیاد هم به صرفه نیست. اما امیدوارم این صحبت ها باعث نشه که فکر کنید در پایتون نمیشه از عملیات همزمانی واقعی استفاده کرد و یا فقط باید به یه CPU بسنده کرد. زبان پایتون نیازی به GIL نداره, این فقط پیاده سازی CPython که از این روش استفاده میکنه و شما توی Jython همچین چیزی رو ندارید. تو مقاله های بعدی بیشتر در مورد این زمینه ها صحبت میکنیم و راه حل های این مشکل رو مورد بررسی قرار میدیم.

منبع : http://amirreza.wordpress.com/category/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C/

 

 |+| نوشته شده در  شنبه سوم فروردین 1387ساعت 11:48 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

اعمال هم زمان در پایتون (بخش اول)

اجرای هم زمان وظایف
کارایی یک نرم افزار فقط زمانی به بالاترین حد خود می رسه که بتونه به درستی از منابع سخت افزاری سیستم استفاده کنه. وقتی در حیطه ی نرم افزار صحبت از منابع سخت افزاری می شه اصولا منظور ما پردازنده و حافظه هست. برنامه ها به هنگام اجرا در پروسه ها یا فرآیندها طبقه بندی می شن. به این صورت که سیستم عامل مقداری از حافظه رو به هر فرآیند تخصیص میده و پردازنده اقدام به پردازش اون فرآیند در حافظه می کنه. به حالت عادی هر پردازنده در هر زمان فقط می تونه یه فرآیند را مورد پردازش قرار بده اما سیستم عامل با زمان بندی مناسب باعث می شه قدرت پردازنده بین تمام فرآیندها تقسیم بشه و چندین فرآیند بتونن به طور هم زمان مورد پردازش قرار بگیرن. به یک همچین عملی ” multi-tasking” یا “چند وظیفه ای” گفته میشه.
multi-tasking این امکان رو میده که چندین برنامه به صورت همزمان اجرا بشن. برای مثال می تونید همزمان با اجرای مرورگر firefox یک فیلم رو هم تو mplayer مشاهده کنید. در سیستم عاملی مثل DOS این امکانات فراهم نبود و فقط یه برنامه در هر زمان می تونست اجرا بشه. در ضمن اگه از چند پردازنده استفاده کنیم و یا پردازنده ی دستگاهمون چند هسته ای باشه کارایی مکانیزم multi-tasking به بالاترین حد خودش می رسه.
تا اینجای کار فهمیدیم که سیستم عامل می تونه با استفاده از multi-tasking چند تا عمل رو در یک زمان انجام بده و با حداکثر استفاده از قدرت پردازنده باعث بشه کارایی برنامه ها بالاتر بره. اما نکته ی قابل توجه اینه که ما می تونیم multi-tasking را در سطح برنامه ی خودمون هم اعمال کنیم. از اونجایی که هر برنامه کامپیوتری از زیربرنامه های مختلف تشکیل میشه ما می تونیم در صورت نیاز اجرای چند زیر برنامه رو به صورت هم زمان انجام بدیم. اما ممکنه این سوال پیش بیاد که این کار چه نفعی می تونه داشته باشده. در جواب این سوال میشه به دو منفعت اساسی این روش استفاده کرد:
1. برنامه ی ما می تونه چند عمل رو در یک زمان انجام بده. مثلا در نظر بگیرید که قراره برنامه ای بنویسیم که می خواد دو جفت عدد رو با هم جمع کنه و در آخر حاصل جمع هر دو جفت رو به خروجی بفرسته. پیاده سازی معمولی این برنامه می تونه به صورت زیر باشه:
جمع جفت اول رو انجام بده.
جمع جفت دوم رو انجام بده.
حاصل جمع جفت اول رو به خروجی بفرست.
حاصل جمع جفت دوم رو به خروجی بفرست.
در اینجا اعمالی که برنامه انجام می ده به ترتیب صورت میگیره. اما مساله اینه که چرا وقتی پردازنده ی ما این قدرت رو داره که بخواد تمام اعمال رو با هم انجام بده, ما از این مزیت استفاده نکنیم؟ پس برنامه رو با استفاده از multi-tasking به صورت زیر بازنویسی می کنیم:
جمع جفت اول و دوم را انجام بده.
حاصل جمع این دو جفت را به خورجی بفرست.
2. کارایی برنامه بالاتر میره. در مثالی که زدم مشاهده کردید که با استفاده ی بهینه تر از قدرت پردازنده, مراحل کاری برنامه ی ما کاهش پیدا کرد. این امر علاوه بر اینکه اجرای برنامه ی ما رو سریعتر میکنه باعث میشه برنامه بهتر از منابع سخت افزاری ای که در اختیارش گذاشته میشه استفاده کنه و بی خود اون ها رو هدر نده.
حالا که با مزیت های multi-tasking آشنا شدیم باید ببینیم که جه جوری می تونیم از این شیوه تو برنامه ها مون استفاده کنیم. برای پیاده سازی multi-tasking در برنامه ها دو راه حل اصلی وجود داره:
1. multi-processing (چند پروسه ای)
multi-processing برای پیاده سازی multi-tasking از پروسه ها یا همون فرآیندها استفاده میکنه. مثلا وقتی می خواهید دو زیر برنامه در برنامه ی شما به طور هم زمان اجرا بشه, multi-processing دو پروسه ی جداگانه ایجاد میکنه و از سیستم عامل مقداری حافظه برای اون ها قرض میگیره. بعدش هر کدوم از این زیربرنامه ها رو داخل این پروسه ها پردازش میکنه. بعد از اینکه پردازش تموم شد مقدار حافظه ای که قرض گرفته بود رو آزاد میکنه و نتیجه ی پردازش رو به برنامه بر میگردونه. دقت کنید که هر پروسه یا فرآیند مخصوص نگه داری یک برنامه مستقل هستش, یعنی وقتی برنامه ی شما این دو پروسه ی جدید رو ایجاد میکنه در واقع داره دو برنامه ی جدید رو به سیستم عامل معرفی میکنه. حتما شما هم فکر می کنید که این شیوه با اینکه عملیات هم زمان سازی رو انجام میده ولی اونطور که باید و شاید از لحاظ سخت افزاری به صرفه نیست. که البته این موضوع هم تا حدودی به معماری سیستم عاملتون بر می گرده.
2. multi-threading (چند نخی)
multi-threading شیوه ی دیگری برای هم زمان سازی اجرای زیربرنامه هاست که سریعتر و سبک تر از multi-processing عمل میکنه. تو این شیوه به جای استفاده از پروسه ها از “نخ ها” (threads) استفاده میشه. نخ ها جریان های شناور داخل پروسه ها هستند که عملیات برنامه رو تقسیم بندی میکنند. به حات عادی هر پروسه فقط یک نخ ایجاد میکنه پس در هر زمان فقط یک عملیات داخل هر پروسه پردازش می شه. multi-threading می تونه چندین نخ را به صورت هم زمان ایجاد کنه تا با این کارهر پروسه بتونه میزان پردازش بیشتری را از پردازنده ی دستگاه درخواست کنه. در این روش به جای اینکه چند پروسه ی جدید ( یا چند برنامه ی جدید ) در حافظه ایجاد بشه, چند نخ جدید در هر پروسه ایجاد میشه و نخ ها از حافظه ای که مختص به همون پروسه هستش استفاده میکنن. این روش سریعتر و بهینه تر از روش multi-processing هست. در ضمن در multi-threading چون نخ ها از حافظه ی جداگانه استفاده نمی کنند, می توانند به راحتی با هم ارتباط داشته باشند و داده هایشان را با هم به اشتراک بگذارن؛ این کاریه که در شیوه ی multi-processing به راحتی قابل انجام نیست چون هر پروسه از حافظه های جداگانه استفاده میکند.
موارد لازم برای شروع کار
نکته ای که اینجا لازمه بگم اینه که اگه بخواین از multi-tasking تو برنامه هاتون استفاده کنید اول باید سیستم عاملی داشته باشید که از multi-tasking پشتیبانی کنه ( که تقریبا همه سیستم عامل ها این کار رو می کنن) و در ضمن زبان برنامه نویسی ای که برای نوشتن برنامه استفاده میکنید باید قابلیت پیاده سازی شیوه های multi-processing و multi-threading رو داشته باشه. (توجه کنید که ارجحیت با multi-threading هستش)
زبان هایی مثل Java, C#, Python و یا Ruby به صورت درونی از این شیوه ها پشتیبانی میکنند. زبان هایی مثل ++C هم هستن که این قابلیت ها رو به صورت درونی ندارن ولی می تونن از این شیوه ها استفاده کنن. البته زبان هایی هم مثل PHP وجود دارن که اصلا همچین چیزهایی رو پیاده سازی نکردن (اگه اشتباه میکنم گوشزد کنین تا اصلاح بشه)
شاید این سوال واستون پیش اومده باشه که چه طور ممکنه C و++C به صورت درونی multi-tasking رو پیاده سازی نکرده باشن ولی بیشترین استفاده از multi-tasking در همین زبان باشه؟ جواب خیلی ساده اس. از اونجایی که این دو زبان جزو زبان های سطح میانی به حساب میان و اصولا برای کارهای سیستمی استفاده میشن, در استاندارد اون ها پیش بینی شده که ممکنه برنامه های C و ++C روی سیستم عاملی استفاده بشن که از multi-tasking پشتیبانی نکنه! و یا شاید اصلا نیاز به multi-tasking وجود نداشته باشه و یا….. به همین خاطر این دو زبان طبق استاندارد هاشون به صورت درونی از multi-tasking پشتیبانی نمی کنن و پیاده سازی اون رو وظیفه ی سازنده های کامپایلر و یا کتابخونه های اضافی می دونن. البته لازم به گفتنه که استاندارد آینده ی ++C که به C++0x مشهور هستش, سازنده های کامپایلر رو مجبور میکنه که عملیات هم زمان سازی رو به صورت دورنی در++C قرار بدن که با این کار ++C رو یک قدم به ساخت برنامه های کاربردی نزدیک تر می کنن و یک قدم هم اونو از مسایل سیستمی دورتر میکنن و با این حساب در آینده باز هم این C هستش که به عنوان یه زبان سیستمی حرف اول رو می زنه.
از معدود زبان های سطح بالا که کاملا multi-tasking ( یا شاید دیگه بهتر باشه بگیم multi-threading ) رو پیاده سازی کردن Java هستش. اکثر زبان ها اون رو به طور کامل و همه جانبه پیاده سازی نکردن که از جمله ی اون ها میشه به Python , Ruby و یا حتی #C اشاره کرد.
حالا که با اصول و مفاهیم اولیه کار آشنا شدیم می تونیم در بخش دوم مقاله به مبحث اصلی خودمون یعنی “اعمال همزمان در پایتون) بپردازیم.
 
 
 |+| نوشته شده در  شنبه سوم فروردین 1387ساعت 11:45 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

Architecting Server/Client Convergence

In this post I argue that the current convergence of Desktop and / Web Apps (RIAs) suggests a convergence of Server and Clients and that this opens up some interesting possibilities.

I have been following an interesting series of posts by Arnon Rotem-Gal-Oz on the web/desktop convergence trend (all four posts are worth reading!). As well, in January and April, Arnon observes software converging towards:

  • the ease of deployment of web applications,
  • the richness and responsiveness of desktop apps,
  • using a unified programming model for the whole app.

Technologies competing for the privilege of delivering some or all of this trifecta include (but are not limited to) AJAX, Adobe Flex, Flash, Adobe Air, Microsoft Silverlight, JavaFX, Google Gears, Mozilla Prism, Aptana’s Jaxer and JNext.

These technologies are being developed in the context of increasing awareness of two trends 1) the possibilities of ‘on-tap’ cloud computing and simultaneously 2) the promise of 100’s of cores in our client computers.

Here are some observations about the current web-app situation:

  • Increasingly, the Virtual Machine environments on the server are being introduced down the tiers and ported to clients. (Silverlight’s CLR, and Java VM come to mind.)
  • The use of Javascript in browsers has taught us about the secure use of mobile code and a similar mechanism could be inductively applied back up the tiers so that servers also are extensible like browsers. (Unlike the movement of server VMs into clients, I am not aware of production or prototype implementations of this.) Aptana’s Jaxer is a great example of this. (Thanks to Peter Svensson for pointing this out.) See Request Based Distributed Computing for a candidate architecture.

What we are seeing is not just a Web/ Desktop Convergence but also the possibility of Server/Client Convergence.

This convergence has the potential to address another problem in the current state of affairs with web apps:

  • Forcing the developer to choose in advance about the location of code execution is like forcing the developer to place a long running bet on the relative performance of the cloud, network and heterogeneous clients.

Actually, this is one of the drivers underlying Microsoft Volta - a technology that is designed to reduce the cost of reassigning portions of an application between server and client. However as Arnon has pointed out it does not provide an abstraction that reinforces the “coarse-grained interface” that works well in the context of the fallacies of distributed computing. Unlike Volta, tier-agnostic requests relies on the same coarse grained interface as AJAX.

Convergence of server and client technologies
However, the convergence of server and client technologies opens up the possibility for Request Based Distributed Computing and tier-agnostic requests to provide a simple mechanism for delaying architectural decisions to run-time as well as supporting:

  • the ease of deployment of web applications,
  • the richness and responsiveness of desktop apps,
  • using a unified programming model for the whole app.

منبع : http://www.davidpratten.com

 

 |+| نوشته شده در  شنبه سوم فروردین 1387ساعت 11:40 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

Adaptive control of Request Based Distributed Computing

The purpose of this post is to illustrate the possibility for autonomic computing inherent in Request Based Distributed Computing (RBDC).

This is how I summarised RBDC in a recent post:

Request Based Distributed Computing is a small extension of the http protocol and notion of server, proxy and client. Rich Internet Applications, SOA architected applications and SETI@home type distributed computing alike can utilise a common unified programming model. No longer will technology dictate the locus of code execution - instead issues like availability of computing power, intellectual property and security will dictate this at run time.

This discussion focuses on the way that RBDC creates two ways to satisfy many http requests. The two ways are illustrated in the following two diagrams. These diagrams are similar to those in a earlier discussion.

In the first scenario (DIAGRAM 1) we see a client requesting resource A and evaluating code locally to satisfy its own http request.

DIAGRAM 1
RBDC Diagram 1

In the second scenario (DIAGRAM 2) we see the same client. However in this case, when the client requests resource A, the client does not tell the server about it’s local computing capacity. In this case the relevant code is evaluated on the server.

DIAGRAM 2
RBDC Diagram 5

The two ways of satisfying the request have differing performances. The relative performance of the two alternatives will be determined by things like the server/client balance of: response time, network bandwidth, and network latency.

A monitor can observe the time to complete each http request and recommend to the client whether to request mobile code or to let the server evaluate the code that generates the resource. This is an adaptive process because during a 24 hour period server availability, network latency and available bandwidth could change radically. Once the monitor has decided on the fastest way to execute a piece of mobile code, it may attempt the evaluation of mobile code in the opposite way once every N requests - in this way keeping its adaptive capability current.

منبع : http://www.davidpratten.com

 

 |+| نوشته شده در  شنبه سوم فروردین 1387ساعت 11:32 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

Distributed Computing with the Browser

Recently, Subbu posted an interesting discussion of an xml analysis and presentation application - you can read it here: Distributed Computing with the Browser.

This design scenario is a good illustration of the limitations of our current situation with programming . Our current situation is that while the WWW allows a programmer to ignore the network path to an information resource, as programmers, we can’t ignore where computing will be done. The programmer’s choice of technology (framework, language etc etc) carries with it the implicit choice about the location of computation (server or client).

An assumption behind Subbu’s post is that we need to decide the location of processing during the design phase. The purpose of this post is explore how the application could be built using Request Based Distributed Computing RBDC (see backgrounder). With the application recast as a RBDC application, the location-of-processing decisions can be made at runtime based on the availability of computing power and storage, intellectual property, and security issues.

The XML analysis and presentation application using RBDC

(This description presumes that you have read the RBDC backgrounder.)

The key distributed process in this application is the initial analysis of the source XML text, and the saving of the key features into a central database. Lets call this “analyse-save”. With RBDC, the code that performs analyse-save may be written as mobile code that will run on either the server, a proxy or on the client. Analyse-save may be implemented as the code that responds to a http POST request that uploads the source file to the server. It analyses the uploaded file then POSTS the results of the analysis to a central database.

When a RBDC compliant server receives the analyse-save request it may perform the analysis itself on the server or otherwise return the analyse-save code to the client. If the client receives code as a response to its analyse-post request then it would execute the code locally. In either case, the results of the analysis are POSTed to the central database using http.

Clients that have local processing capabilities signal through a http header in the POST request that they are able to accept mobile code as a response to the request. Alternatively clients without processing ability can make the same request signalling that they need the server to do all possible processing.

In this way - the architecture of the solution is the same for Subbu’s cases 1 and 3 with the decision about location of processing being made at runtime, not as part of the design.

منبع : http://www.davidpratten.com

 

 |+| نوشته شده در  شنبه سوم فروردین 1387ساعت 11:29 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

HTC and Cloud and Grid Computing

The HyperText Computing (HTC) paradigm is not a “complete solution” to the challenges and opportunites afforded by Cloud and Grid computing — however this post argues that the HTC is part of the solution. My angle into this question is via a recent blog post.

This is how Tim Foster, in a recent post at Grid Gurus, concludes his discussion of current and future trends of Cloud and Grid computing (emphasis mine):

In building this distributed “cloud” or “grid” (“groud”?), we will need to support on-demand provisioning and configuration of integrated “virtual systems” providing the precise capabilities needed by an end-user. We will need to define protocols that allow users and service providers to discover and hand off demands to other providers, to monitor and manage their reservations, and arrange payment. We will need tools for managing both the underlying resources and the resulting distributed computations. We will need the centralized scale of today’s cloud utilities, and the distribution and interoperability of today’s grid facilities.

The concepts that Tim highlights: “on-demand provisioning”, “configuring integrated virtual systems”, providing “precise capabilities” and a focus on the needs of the “end-user” are all addressed by the HyperText Computing (HTC) paradigm. HTC also addresses the need to view central resources through the same lens as localised ones.

The HyperText Computing (or Request Based Distributed Computing - RBDC) — is a small extension of http and our conceptions of server, proxy and client. It creates a distributed computing platform that is built from an end-user perspective outwards just as http does for information. It is built on a recognition of the equivalence between http resources and the code that when executed will return the resource. RBDC unifes programming models by applying browser based sandboxed Virtual Machines (VM) to our conception of proxies and servers.

Key benefits of RBDC are ultra-lightweight distributed computing, run-time code mobility, and backwards compatibility with http.

A fuller description of RBDC may be found here.

Http offers location transparency for retrieving data, a small http extension can also provide location transparency for code execution.

منبع : http://www.davidpratten.com

 

 |+| نوشته شده در  شنبه سوم فروردین 1387ساعت 10:28 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

Globus Selected as a Google Summer of Code 2008 Mentoring Organization

iStock_000002311523Small.jpgThe Globus Alliance has been selected as a Google Summer of Code 2008 mentoring organization. Google Summer of Code (GSoC) is a program that offers student developers stipends to write code for various open source projects. Google works with several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Historically, the program has brought together over 1,500 students with over 130 open source projects to create millions of lines of code. The program, which kicked off in 2005, is now in its fourth year.

If you are a student and would be interested in participating in GSoC with Globus as your mentoring organization, please take a look at our GSoC Ideas page. This page lists projects that Globus has proposed for GSoC, but it is not a closed list. If you have an idea for a cool project that uses or extends Globus technologies, please take a look at our list of Globus GSoC mentors and contact the one which most closely matches your interests. Take into account that student proposals must be submitted by March 31st and that you must meet Google's student eligibility criteria.

If you have any questions about our participation in GSoC, please contact the Globus GSoC administrators.

منبع : http://gridgurus.typepad.com

 

 |+| نوشته شده در  جمعه دوم فروردین 1387ساعت 3:44 بعد از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

All Jobs Are Not Created Equal

handstand_000004002888XSmall.jpgChoosing a distributed resource management (DRM) software may not be a simple task. There are a number of open source or commercial software packages available, and companies usually go through product evaluation phase in which they consider factors like software license and support costs, maintenance issues, their own use cases and existing/planned infrastructure, etc. After following this (possibly lengthy) procedure, and finally making the decision, purchasing and installing the product, you should also make sure that the DRM software configuration fits your cluster usage and needs. In particular, designing the appropriate queue structure, configuring resources, resource management and scheduling policies are some of the most important aspects of your cluster configuration. At first glance devoting your company's resources into something like queue design might seem unnecessary. After all, how can one go wrong with the usual "short", "medium" and "long" queues? However, the bigger your organization is and the more diverse computing needs of your users are, the more likely it is that you would benefit from investing some time into designing and implementing queues more efficiently. My favorite example here involves high priority jobs that must be completed in a relatively short period of time, regardless of how busy the cluster is. Such jobs must be allowed to preempt computing resources from other lower priority jobs that are already running. Better DRMs usually allow for such use case (e.g., by configuring "preemptive scheduling" in LSF, or using "subordinated queues" in Grid Engine), but this is clearly something that has to be well thought through before it can be implemented. In any case, when configuring DRM software, it is important to keep in mind that not all jobs (or not all users for that matter) are created equal...
 
منبع : http://gridgurus.typepad.com
 
 |+| نوشته شده در  جمعه دوم فروردین 1387ساعت 3:43 بعد از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

پژوهشگران ژاپني تجهيزات نويني براي سوپر رايانه نسل آينده ساختند

توكيو - پژوهشگران وابسته به دانشگاه صنعتي توكيو و شركت الكترونيكي ان .

ايي .سي موفق به ساخت تجهيزات نويني شدند كه وجود آن براي ساخت سوپر رايانه‌هاي نسل آينده ضروري است .

به گزارش ايرنا، روزنامه ژاپني نيهون كيزاي نوشت: كار ين تجهيزات ساخته شده ، پيوند دادن مدارهاي ال. اس. آي رايانه به يكديگر با استفاده از سيگنال‌هاي نوري است .

پژوهشگران در جريان يك آزمايش موفق شدند،با بهره‌گيري از اين تجهيزات كه اندازه آن ‪ ۱۰‬سانتيمتر مربع است ، در هر ثانيه ‪ ۲۵‬گيگا بيت اطلاعات ارسال كنند.

اين براي نخستين بار در جهان است كه با اين شتاب فراوان اطلاعات در داخل رايانه ارسال مي‌شود.

به نوشته اين روزنامه، دولت ژاپن برنامه ريزي كرده است تا سال ‪۲۰۱۰‬ ميلادي سوپررايانه نسل آينده‌اي را بسازد كه در هر ثانيه بتواند ‪ ۱۰‬پتا بار محاسبه انجام دهد و احتمال اين وجود دارد كه از اين دستاورد نوين پژوهشگران دانشگاه صنعتي توكيو و شركت ان .ايي .سي در آن استفاده شود.

هر پتا برابر با هزار تريليون است .


منبع : خبرگزاري جمهوري اسلامي ‪

http://www1.irna.ir/fa/news/view/menu-152/8612295360091731.htm

 

 |+| نوشته شده در  جمعه دوم فروردین 1387ساعت 3:15 بعد از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام
سیستم های ردیابی و کشف نفوذ توزیع شده - dIDS

سیستم های ردیابی و کشف نفوذ توزیع شده که با dIDS از آن یاد می کنیم،از چندین IDS در یک شبکه بزرگ تشکیل شده اند. تمامی این Intrusion Detection System ها، در ارتباط با یدیگر هستند و یا به وسیله یک سیستم (شاید یک سرور) مرکزی در حال پایش شبکه، تحلیل رویدادها و جمع آوری اطلاعات حمله های شناسایی شده، می باشند. این ترکیب برای جمع آوری اطلاعات امکان ایجاد یک دید وسیع برای تیم امنیتی/نگهدارنده شبکه در مورد وقایعی که در هر لحظه در حال جریان است را فراهم می کند.

یک distributed IDS به سازمان ها و اپراتورهای شبکه اجازه می دهد تا به صورت موثر و مستند منابع شبکه ای و سازمانی خود را تحت کنترل قرار دهند و در صورت نیاز به سرعت اطلاعات مورد نیاز را از سیستم بیرون بکشند. برای آشنایی بیشتر مقاله زیر را بخوانید:

An Introduction To Distributed Intrusion Detection Systems

Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred.

تبادل اطلاعات بین IDS ها در سه گونه تقسیم بندی می شود. دسته اول محصولاتی که برای dIDS طراحی شده اند و با استفاده agentهای مختلف در نقاط مختلف شبکه اطلاعات را برای سرور کنترلی IDS ارسال می کنند. دسته دوم محصولاتی که شامل IDS هایی از یک دسته هستند و لاگ فایل های خود را در یک محل متمرکز ذخیره می کنند و مانند دسته اول ادامه کار می دهند. و بالاخره دسته سوم که شامل IDS ها و IPS های (به طور کلی آن ها را sensor خطاب می کنیم.) مختلف از مارک های متفاوتی هستند که به وسیله ابزار های مدیریت سیستم های امنیتی لاگ فایل ها را ذخیره و پردازش می کنند. استاندارد تبادل اطلاعات در سنسور ها، در قالب یک پیش نویس استاندارد IETF در حال شکل گیری است.

The Intrusion Detection Message Exchange Format (IDMEF) is intended to be a standard data format that automated intrusion detection systems can use to report alerts about events that they deem suspicious. The development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal implementation.

به دو علت پروژه های کمی در مورد dIDS هم اکنون وجود دارد. اولین مورد عدم درک نیاز به چنین سیستمی در بخش تجاری و صنعتی و دلیل دوم نو بودن چنین ترکیبی است. همانطور که پیشتر گفتم، IDMEF هنوز به حالت استاندارد در نیامده است. البته جایگزینی این سیستم به وسیله سیستم های یکپارچه مدیریت امنیت گران قیمت نیز دلیل دیگری در کم بودن پروژه ها است. تعدادی از این پروژه ها را در freshmeat ببینید. بدنیست نگاهی هم به پروژه رو به پیشرفت Prelude Hybrid IDS ( حداقل What is Prelude Hybrid IDS را بخوانید.) بندازید.

* این مطلب مقدمه ای است برای سری نوشته های امنیت در عمق که در Secure2S بیشتر در مورد آن ها خواهید خواند. لطفا نظرات و پیشنهادات خود را در میان بگذارید. مجموعه نوشته های امنیت در عمق، تلاش خواهد کرد تا به امنیت در شبکه های بزرگ و تجاری و همچنین نکات امنیتی که کمتر به آن ها پرداخته می شود بپردازد.

منبع : http://secure2s.net/fa/1385/11/11/distributed-ids/

 

 |+| نوشته شده در  جمعه دوم فروردین 1387ساعت 11:1 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

بیت‌تورنت چیست؟

بیت‌تورنت (BitTorrent) هم نام برنامه کاربردی مشتری  بر مبنای توزیع فایل در شبکه‌های نظیر-به-نظیر  است و هم نام یک پروتکل اشتراک فایل، که هر دو در آوریل 2001 توسط برنامه‌نویسی به نام برام کوهن ایجاد شده‌اند. بیت‌تورنت به منظور توزیع حجم بزرگی از اطلاعات بدون کاهش در مصرف منابع پر هزینه سرور و پهنای باند طراحی شده است.

  • بیت‌تورنت چیست؟

  • اصطلاحات BitTorrent

  • BitTorrent چگونه کار می‌‌کند؟

    بیت‌تورنت چیست؟

    اولین برنامه کاربردی BitTorrent به زبان Python نوشته شد و source code آن با ورژن 4.0 تحت لیسانس BitTorrent open source ارائه شد. تعداد زیادی از کلاینت ها (نرم افزارها) با زبان های مختلفی برای اجرا بر روی پلت فورم های مختلف، نوشته شده اند.

    BitTorrent پروتکلی ست که به منظور ارسال فایل طراحی شده است. در واقع نوعی ارتباط peer-to-peer می‌‌باشد که کاربران مستقیما به یکدیگر متصل می‌‌شوند و به ارسال و دریافت قسمتی از فایل می‌‌پردازند. گر چه فعالیت های تمامی کاربران توسط یک سرور مرکزی به نام Tracker هماهنگ می‌شود، اما این سرور از محتویات فایل هایی که منتقل می‌شود بی اطلاع است. در نتیجه تعداد زیاده از کاربران با پهنای باند محدود Tracker مربوطه قابل پشتیبانی هستند. فلسفه کلیدی BitTorrent اینست که کاربران باید همزمان با دان لود کردن اطلاعات (دریافت inbound)، آپلود (ارسال outbound) نمایند. در این صورت پهنای باند شبکه با حداکثر کارایی بکار گرفته می‌شود. BitTorrent به نحوی طراحی شده است که بر خلاف پروتوکل های انتقال دیگر با افزایش تعداد افراد مشتاق برای دریافت یک فایل مشخص، کارا تر می‌شود. برای توصیف بهتر این روند می‌‌توان آن را به گروهی از افراد تشبیه کرد که دور یک میز نشسته اند. هر کدام از این افراد سعی دارند که کپی کاملی از یک کتاب را دریافت کنند. نفر اول اعلام می‌‌کند که صفحات 1-10، 23، 42-50 و 75 را دارد و نفرات سوم، چهارم و پنجم هر کدام قسمت هایی از این صفحات را ندارند. بنابراین هر یک برای گرفتن صفحات، خود را با نفر اول هماهنگ می‌‌کنند. نفر دوم اعلام می‌‌کند که صفحات 11-22، 31-37 و 63-70 را دارد. نفر اول، چهارم و پنجم به نفر دوم می‌‌گویند که بعضی از صفحات او را می‌‌خواهند و او هم کپی آن صفحات را به آنها می‌‌دهد. این روند ادامه می‌‌یابد تا وقتی که همه افراد کپی تمام کتاب را به دست بیاورند. همچنین دور این میز شخص دیگری وجود دارد که کپی کل کتاب را دارد. بنابراین احتیاج ندارد که برایش کپی صفحه‌ای فرستاده شود. او صفحاتی را که هیچ کس ندارد بین افراد پخش می‌‌کند. در ابتدا هنگامی که افراد دور میز می‌‌نشینند، باید از او بخواهند که اولین سری کپی صفحات خود را به آنها بدهد. گرچه افراد سعی می‌کنند که صفحات مشابه را از او نگیرند، بعد از مدتی همگی اکثر کپی کتاب را دارند. بدین ترتیب این فرد می‌‌تواند کتابی را که دارد در اختیار افراد زیاده قرار دهد بدون اینکه مجبور باشد کل کپی را به تمام افراد بدهد. او می‌‌تواند در عوض، قسمت های مختلف کتاب را به افراد متفاوت بدهد. و آنها قادر خواهند بود که این قسمت ها را در بین خود پخش کنند. به این فرد که کل کتاب را در اختیار دارد، در اصطلاح BitTorrent، Seed یا دانه گفته می‌شود. BitTorrent با برنامه‌های کاربردی peer-to-peer دیگر مانند WinMX, Kazza, Gnutella, Emule و ... فرق دارد و مثل آنها محدوده مشخصی ندارد. به عبارت دیگر BitTorrent به وب اضافه شده است به این معنی که تمامی عملیات جستجو و تهیه لیستی از فایل های در دسترس در وب انجام می‌شود و هنگامی که فایل مورد نظر را پیدا کردیم با کلیک بر روی آن، برنامه کلاینت اجرا می‌شود و شروع به دریافت می‌‌کند.


    اصطلاحات BitTorrent

    مفاهیم مختلفی در ارتباط با BitTorrent وجود دارند که به معرفی آنها می‌‌پردازیم.

    torrent یا سیل (جریان شدید) : این اصطلاح معمولا به فایل متادیتای کوچکی گفته می‌شود که از وب سرور(web server) با پسوند .torrent در یافت می‌‌کنیم. متادیتا در اینجا به معنی فایلی ست که اطلاعاتی در مورد داده‌ای که می‌‌خواهیم دان لود کنیم دارد و نه خود داده. این فایل هنگامی که بر روی لینک دان لود آن در یک وب سایت کلیک می‌‌کنید، به کامپیوتر ما فرستاده می‌شود. همچنین می‌‌توان فایل torrent را بر روی سیستم محلی خود ذخیره کنیم و بعدها با کلیک بر روی آن، اقدام به دریافت آن کنیم.

    Peer یا قرینه : Peer کامپیوتر دیگری ست که به آن متصل شده و داده را منتقل می‌‌کنیم. معمولا یک Peer تمام فایل را ندارد. در غیر این صورت به آن Seed می‌‌گوییم. همچنین به Peer ها Leech یا زالو هم گفته می‌شود که از کامپیوترهایی که دان لود خود را کامل کرده‌اند و کلاینت BitTorrent خود را فعال نگهداشته و به صورت Seed عمل می‌‌کنند، متمایز شوند.

    Leech یا زالو : به Peerای گفته می‌شود که به خاطر نسبت اشتراک پایین خود بر روی swarm تاثیر منفی می‌‌گذارد. به بیان دیگر بیشتر از اینکه آپ لود کند، دان لود می‌‌کند. اکثر Leechها، کاربرانی هستند که اتصالات نامتقارن دارند و کلاینت BitTorrent خود را بعد از اتمام دان لود برای عمل seeding باز نمی‌گذارند. حتی بعضی از Leechها به عمد با کلاینت های تنظیم شده و یا محدود کردن سرعت ارسال، از آپ لود کردن جلوگیری می‌‌کنند. با این وجود اصطلاح Leech می‌‌تواند به جای Peer نیز بکار گرفته شود.

    Seed یا دانه : کامپیوتری ست که کپی کامل یک torrent مشخص را دارد. هنگامی که کامپیوتر ما به طور کامل فایل را دان لود کرد، تا زمانی که روی دکمهٔ پایان کلیک نکنیم و یا به هر طریق آن را نبندیم، باز باقی می‌‌ماند. به این عمل Seed بودن و یا Seeding می‌‌گویند. همچنین می‌‌توانیم یک کلاینت BitTorrent را با فایل کاملی شروع کنیم. به محض اینکه BitTorrent فایل را امتحان کرد، متصل شده و فایل مربوطه را برای افراد دیگر Seed می‌‌کند. در کل، بهتر است بعد از اینکه فایلی را به طور کامل دریافت کردیم، برای کمک به دیگران آن را Seed کنیم. همچنین هنگامی که فایل torrent جدیدی به Tracker فرستاده می‌شود، باید حداقل یک Seed موجود باشد که آن را برای دیگران قابل دستیابی کند. به یاد داشته باشید که Tracker هیچ چیز در مورد محتوای واقعی فایل ها نمی‌داند. بنابراین مهم است که بعد از upload کردن یک فایل torrent در Tracker، آن را Seed کنیم.


    Reseed یا کاشت دوباره : هنگامی که هیچ Seed ای برای فایل تورنت مورد نظر موجود نباشد و Peer ها با هم، کل فایل را نداشته باشند، تمامی Peer ها فایل ناقصی دارند و هیچ یک، قسمت های تکمیل کننده را ندارد. در این صورت کامپیوتری با فایل کامل (Seed)، باید به Swarm (گروه و دسته) متصل شود و قسمت های ناقص فایل را ارسال کند. این عمل کاشت دوباره نام دارد. معمولا یک درخواست برای عمل Reseed با تعهدی همراه است مبنی بر اینکه بعد از دان لود کامل فایل، فرد درخواست کننده باید برای مدت زمان مشخصی به منظور افزودن طول عمر به فایل تورنت به عنوان یک Seed عمل کند.

    Swarm یا گروه و دسته : به گروهی از ماشین ها گفته می‌شود که به طور مشترک و جمعی برای یک فایل خاص به یکدیگر متصل هستند. برای مثال اگر یک کلاینت BitTorrent را راه اندازی کنیم و به ما بگوید که به 10 Peer و 3 Seed متصل هستیم، Swarm شامل کامپیوتر ما و 13 نفر دیگر است.

    Tracker یا ردیاب : سروری ست در اینترنت که فعالیت های کلاینت های BitTorrent را هماهنگ می‌‌کند. هنگامی که تورنتی را باز می‌‌کنیم، ماشین ما با Tracker ارتباط برقرار می‌‌کند و لیستی از Peer ها را برای تبادل اطلاعات دریافت می‌‌کند. این کار به طور دوره‌ای و متناوب صورت می‌‌گیرد و Tracker میزان دان لود و آپ لود، میزان باقی مانده از فایل و وضعیتی که در حال حاضر داریم (شروع، پایان دان لود و توقف) را به ما نشان می‌‌دهد. اگر Tracker از کار بیفتد و بخواهیم یک تورنت را باز کنیم، قادر نخواهیم بود. اگر بعد از اتصال در حین ارتباط با Peer ها و دان لود کردن فایل تورنت، Tracker از کار بیفتد، قادر به ادامه انتقال با آن Peer ها خواهیم بود ولی هیچ Peer جدیدی قادر به برقرار کردن ارتباط با ما نخواهد بود. معمولا خطاهای Tracker ها موقتی هستند. بنابراین بهترین کار اینست که صبر کنیم و کلاینت را باز نگهداریم تا به سعی خود ادامه دهد.

    Downloading یا دریافت کردن : به عمل دریافت داده از کامپیوتر دیگر دان لود کردن می‌‌گویند.

    Uploading یا ارسال : به عمل فرستادن و ارسال داده به کامپیوتر دیگر گفته می‌شود.

    Share rating یا سرعت اشتراک : اگر از یک کلاینت آزمایشی با stats-patch استفاده می‌‌کنیم، می‌‌توانیم سرعت اشتراک را در یک پنل GUI مشاهده کنیم. که نشان دهندهٔ نسبت مقدار آپ لود شده به مقدار دان لود شده است. مقدارهای بکار برده شده، تنها برای قسمتهای در حال انتقال هستند نه برای کل فایل. اگر نسبت اشتراک نشان داده شده برابر با 1 باشد، بدین معنی ست که به همان میزانی که آپ لود نموده ایم، دان لود کرده ایم. هر چه این عدد بزرگ تر باشد نشان دهنده اینست که یه میزان بیشتری ارسال کرده اید. اگر این نسبت 0 بود، به این معنی ست که شما کل فایل را دریافت نموده اید و به عنوان Seed فعالیت می‌‌کنید. بنابراین هر چه بیشتر به ارسال ادامه دهید میزان این نسبت به سمت بی نهایت می‌‌رود. این نسبت تنها به منظور آگاهی کاربران محاسبه می‌شود. در کل برای کمک به دیگران بهتر است همیشه این نسبت را به حداکثر مقدار برسانیم.

    Distributed Copies یا کپی های توزیع شده : در بعضی از ورژن های کلاینت ها (نرم افزارها)، عبارت "متصل به n عدد seed و در حال مشاهده n.nnn کپی توزیع شده" را مشاهده می‌‌کنید. یک Seed ماشینی با فایل کامل است. با این وجود، Swarm می‌‌تواند در مجموع، کل فایل را داشته باشد بدون اینکه Seedای داشته باشد. و این همان چیزی ست که این عبارت بیان می‌‌کند.

    Choked یا مسدود شده : این اصطلاحی ست که در پروتوکل BitTorrent بکار رفته است و به حالتی از یک ارسال کننده فایل (uploader)اشاره دارد. وقتی که یک اتصال مسدود شده است به معنی ست که ارسال کننده در حال حاضر نمی‌خواهد داده‌ای به آن لینک ارسال کند. کلاینت BitTorrent، بنا به دلائلی سیگنالی به کلاینت های دیگر می‌‌فرستد که مسدود شدن این لینک را اعلام کند. اما معمولا بطور پیش فرض یک کلاینت (کلاینتی که بیشترین آپ لود را داشته است) آپ لود های فعال خود را باز می‌‌گذارد و بقیه کلاینت ها مسدود اعلام می‌‌شوند. مقدار پیش فرض 4 می‌‌باشد که مشابه تنظیمات کلاینت BUI آزمایشی ست که می‌‌توان تغییر داد. یک اتصال می‌‌تواند به دلائل دیگری نیز مسدود شود. به طور مثال هنگامی که یک Peer مشغول دریافت فایلی از یک Seed است که نمی‌خواهد داده‌ای را ارسال کند، اتصالش مسدود شده اعلام می‌شود. توجه داشته باشید که اگر هر اتصال دوطرفه و قرینه باشد، دو علامت نمایش انسداد برای هر اتصال (انتهای هر ارسال کننده) خواهیم داشت.

    Interested یا مشتاق : اصطلاح دیگری ست که در پروتوکل BitTorrent بکار برده می‌شود که در نتیجهٔ علامت انسداد ایجاد شده است و به نشان دهندهٔ حالتی ست که فرد دان لود کننده در انتظار اتصال و دریافت قسمتی از فایل است. فرد دان لود کننده هنگامی مشتاق نامیده می‌شود که در کلاینت مقابل، قسمتی از فایل موجود باشد که این فرد احتیاج دارد.

    Snubbed یا منع شده : اگر کلاینت هیج داده‌ای را بعد از مدت زمان مشخصی (بطور پیش فرض 60 ثانیه) دریافت نکند، منع شده نامیده می‌شود. این حالت هنگامی رخ می‌‌دهد که از ارسال Peer مقابل، برای مدتی جلوگیری شده باشد. بعضی از اوقات کلاینت در حالتی قرار می‌‌گیرد که با اینکه به تعداد زیادی از Peer ها متصل است، ولی توسط تمام آنها مسدود شده است. این کلاینت از علامت منع شده استفاده می‌‌کند تا از این موقعیت خارج شود. این علامت نشان می‌‌دهد که یک Peer که می‌‌خواهد تکه هایی از فایل را انتقال دهد، برای مدتی چیزی ارسال نکرده است.



    Optimistic unchoking یا اتصال مجدد خوشبینانه : کلاینت ها به طور متناوب، لیستی از ارسال کننده ها را بازنگری می‌کنند و تلاش می‌کنند تا اتصالات جدیدی را که قبلا مسدود شده بودند، برقرار کنند و اتصالاتی را که برقرار کرده بودند را مسدود کنند. این اعمال را می‌‌توان هر 10 یا 20 ثانیه با مشاهدهٔ "Advanced" از یکی از کلاینت ها بررسی کرد.


    BitTorrent چگونه کار می‌‌کند؟


    پروتوکل BitTorrent فایل ها را به تکه‌های کوچک، معمولا یک چهارم مگابایت (256 KB) می‌‌شکند. هر چه اندازهٔ فایل بزرگتر باشد، تکه ها نیز بزرگتر خواهند بود. به طور پیش فرض اندازه تکه ها برای یک فایل 4.37 گیگا بایتی، 4 مگابایت می‌‌باشد. Peerها تکه هایی را که ندارند از یکدیگر دان لود می‌کنند و تکه هایی را که Peer های دیگر ندارند برایشان آپ لود می‌‌کنند. این پروتوکل به اندازهٔ کافی هوشمند است که Peerای را انتخاب کند که بهترین اتصال را داشته باشد. برای بالا بردن کارایی کل swarm، کلاینت های BitTorrent قسمتهایی را درخواست می‌کنند که کمیاب ترند. به عبارت دیگر قسمتهایی که در Peer های کمتری وجود دارند، می‌‌توانند برای Peer های بیشتری مفید باشند. تکه‌های فایل ها معمولا به ترتیت دان لود نمی‌شوند و احتیاج به مرتب سازی در ماشین دریافت کننده دارند. توجه داشته باشید که کلاینت ها قبل از اینکه کل فایل دان لود شود، تکه ها را برای Peerهای دیگر آپ لود می‌‌کنند. بنابراین اشتراک گذاری برای هر Peer با یک فایل کوچک با پسوند .torrent آغاز می‌شود که یک فایل اشاره گر (pointer) است که شامل اطلاعاتی از قبیل نام فایل و اندازه آن دارد.

    دان لود کردن با BitTorrent بسیار آسان است. با یک فایل با پسوند .torrent آغاز می‌شود. هر فرد که می‌‌خواهد فایل را دان لود کند، ابتدا باید این فایل کوچک را دریافت نماید و آن را توسط نرم افزارهای کلاینت BitTorrent باز کند. فایل تورنت، آدرس tracker ای را که لیستی از کاربرانی که مشغول دان لود فایل هستند و محل قرار گرفتن تکه‌های فایل را می‌‌داند، به کلاینت می‌‌دهد. برای هر منبع قابل دسترس، کلاینت متوجه می‌شود که کدام بلاک از فایل مورد نظر قابل دستیابی هستند. به محض اینکه کلاینت دریافت یک بلاک را کامل کرد، آن را هش (Hash) می‌‌کند تا مطمئن شود که این بلاک با فایل تورنت متناسب است. سپس به دنبال کسی می‌‌گردد که این فایل را برایش آپ لود کند.

    اگرچه BitTorrent پروتوکل خوبی برای کاربران پهن باند (BroadBand) می‌‌باشد، برای اتصالات dial up که بطور مداوم قطع می‌‌شوند، کمتر کارایی دارد. به بیان دیگر سرورهای HTTP زیادی اتصالات خود را برای ساعات طولانی قطع می‌‌کنند. در حالیکه تورنت های زیادی وجود دارند که هنوز دان لود خود را تکمیل نکرده اند.

منبع: wikipedia

 

 |+| نوشته شده در  جمعه دوم فروردین 1387ساعت 10:25 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

تفاوت های CPU های AMD وIntel

-AMD براساس معماری اجرایی 9 مرحله ای ساخته شده است اما معماری پردازنده های Intel شش مرحله ای می باشد.بدین معنا که AMDدر هر چرخه کاری 9عملیات را انجام میدهد در حالی که Intel فقط 6 عمل را می تواند انجام دهد.
2-AMD از640Kb Cache برخوردار است در حالی که Intel ، از 532Kb بر خوردار است هر چقدر که میزان Cache پردازنده بیشتر باشد ، پردازنده کارایی بیشتری خواهد داشت اطلاعات بیشتری میتواند ذخیره کند ودیگر لازم نیست پردازنده برای بدست آوردن اطلاعات یا دستور ها مدت زمان بیشتری را رفت و برگشت به حافظه برد اصلی برای جذب اطلاعات یا دستور العمل ها صرف کند.
3- AMD از مس برای اتصال ترانزیستور های بکار رفته در پردازنده ها استفاده میکند در صورتی که در ساختمان پردازنده های Intel آلومینیوم بکار رفته است.مس هادی الکترسیته بهتری است ، ازاین رو پهنای اتصالهای بین ترانزیستورها را به میزان چشمگیری کاهش می یابد .که این امر باعث مصرف کمتر مواد اولیه و در نتیجه منجر به کاهش هزینه می شود این دلیل ارزان تر بودن AMD نسبت به P4 است.
4- از دیگر تفاوت های میان AMD وIntel میتوان به راندمان Cache بروی چیپ اشاره کرد ، AMD از معماری انحصاری استفاده میکند که راندمان بیشتری نسبت بیشتری نسبت به طراحی معماری غیر انحصاری Intel دارد.
5-AMD از تکنولوژی پردازش موازی در مقایسه با Hyper -Threading اینتل استفاده میکند ، در بسیاری از کاربردهای امروزی فعال بودن Hyper -Threading کارائی پائین تری ارائه میدهد ، نتایج تحقیقات بیشمار منتشر شده در نشریات رایانه ای و پایگاهای اطلاعاتی معتبر بیانگوی این پدیده هستند.
6-یکی دیگر از مهمترین نکات برتر پردازنده های AMD واحد ممیز شناور آن است که از FPU اینتل بسیار قویتر میباشد که این امر باعث اجرای سریع تر برنامه های چند منظوره( MultiMedia) میشود.
7- زمانی که اینتل P4 را طراحی کرد طول PIPELINE را از 10 مرحله در P3 به 20 مرحله افزایش داد Intel همین تغیر توانست که تعداد عملیاتی که در چرخه عملیاتی انجام می شود بصورت قابل ملاحظه ای کاسته میشود و از طرف دیگر افزایش طول PIPELINE نیازمند افزایش تعداد ترانزیستور ها برای انجام همان تعداد عملیات میباشد که این امر باعث افزایش اندازه هسته و بالا رفتن قیمت تولید میشود . در حالی که AMD با وجود افزایش فرکانس پردازنده های خود طول pipeline را به همان اندازه p3 یا k6 ثابت نگهدارد .

 

 |+| نوشته شده در  جمعه دوم فروردین 1387ساعت 9:59 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

اصول گزيده اي از کامپيوترهاي کوانتومي

خلاصه

فيزيك كوانتومي مهم ترين دستاورد علم بشري در توصيف طبيعت است. اين نظريه كه در سالهاي 27-1925 توسط «ورنر هايزنبرگ»، «اروين شرودينگر»، «پل ديراك»، «ماكس پلانك» و چند تن ديگر پايه گذاري شد، اساس تمام ادراك امروزي ما از عالم است. به بيان دقيق تر، مكانيك كوانتومي مجموعه اي از قوانين، روابط رياضي و مفاهيم فلسفي است كه توصيف كننده رفتار ذرات بنيادين تشكيل دهنده عالم است. البته با تعميم همين قوانين و روابط، مي توان رفتار تمام سيستم هاي فيزيكي اي كه پيش از آن بررسي شده بودند را نيز بررسي و تعيين كرد.

 

اصول گزيده اي از کامپيوترهاي کوانتومي

 

         روياي محاسبات ماشيني يا ماشيني كه بتواند مسائل را در اشكال گوناگون حل كند كمتر از دو قرن است كه زندگي بشر را به طور جدي در بر گرفته است. اگر از ابزارهايي نظير چرتكه و برخي تلاشهاي پراكنده ديگر در اين زمينه بگذريم، شايد بهترين شروع را بتوان به تلاشهاي «چارلز بابيج» و « بلز پاسكال» با ماشين محاسبه مكانيكي شان نسبت داد. با گذشت زمان و تا ابتداي قرن بيستم تلاشهاي زيادي جهت بهبود ماشين محاسب مكانيكي صورت گرفت كه همه آنها بر پايه رياضيات دهدهي (decimal) بود، يعني اين ماشين ها محاسبات را همان طور كه ما روي كاغذ انجام مي دهيم انجام مي دادند. اما تحول بزرگ در محاسبات ماشيني در ابتداي قرن بيستم شروع شد. اين زماني است كه الگوريتم و مفهوم فرايندهاي الگوريتمي (algorithmic processes) به سرعت در رياضيات و بتدريج ساير علوم رشد كرد. رياضيدانان شروع به معرفي سيستم هاي جديدي براي پياده سازي الگوريتمي كلي كردند كه در نتيجه آن، سيستم هاي انتزاعي محاسباتي بوجود آمدند. در اين ميان سهم برخي بيشتر از سايرين بود.

         آنچه امروزه آنرا دانش كامپيوتر و يا الكترونيك ديجيتال مي ناميم مرهون و مديون كار رياضيدان برجسته انگليسي و يكي از غولهاي انديشه قرن بيستم به نام «آلن تورينگ» (Alan Turing) است. وي مدلي رياضي را ابداع كرد كه آنرا ماشين تورينگ مي ناميم و اساس تكنولوژي ديجيتال در تمام سطوح آن است. وي با پيشنهاد استفاده از سيستم دودويي براي محاسبات به جاي سيستم عدد نويسي دهدهي كه تا آن زمان در ماشين هاي مكانيكي مرسوم بود، انقلابي عظيم را در اين زمينه بوجود آورد. پس از نظريه طلايي تورينگ، ديري نپاييد كه «جان فون نويمان» يكي ديگر از نظريه پردازان بزرگ قرن بيستم موفق شد ماشين محاسبه گري را بر پايه طرح تورينگ و با استفاده از قطعات و مدارات الكترونيكي ابتدايي بسازد. به اين ترتيب دانش كامپيوتر بتدريج از رياضيات جدا شد و امروزه خود زمينه اي مستقل و در تعامل با ساير علوم به شمار مي رود. گيتهاي پيشرفته، مدارات ابر مجتمع، منابع ذخيره و بازيابي بسيار حجيم و كوچك، افزايش تعداد عمل در واحد زمان و غيره از مهم ترين اين پيشرفتها در بخش سخت افزاري محسوب مي شوند. در 1965 «گوردون مور» اظهار كرد كه توان كامپيوترها هر دو سال دو برابر خواهد شد. در تمام الين سالها، تلاش عمده در جهت افزايش قدرت و سرعت عملياتي در كنار كوچك سازي زير ساختها و اجزاي بنيادي بوده است. نظريه مور در دهه هاي 60 و 70 ميلادي تقريبا درست بود. اما از ابتداي دهه 80 ميلادي و با سرعت گرفتن اين پيشرفتها، شبهات و پرسش هايي در محافل علمي مطرح شد كه اين كوچك سازي ها تا كجا مي توانند ادامه پيدا كنند؟ كوچك كردن ترازيستورها و مجتمع كردن آنها در فضاي كمتر نمي تواند تا ابد ادامه داشته باشد زيرا در حدود ابعاد نانو متري اثرات كوانتومي از قبيل تونل زني الكتروني بروز مي كنند. گرچه هميشه تكنولوژي چندين گام بزرگ از نظريه عقب است، بسياري از دانشمندان در زمينه هاي مختلف به فكر رفع اين مشكل تا زمان رشد فن آوري به حد مورد نظر افتادند. به اين ترتيب بود كه براي نخستين بار در سال 1982 «ريچارد فاينمن» معلم بزرگ فيزيك و برنده جايزه نوبل، پيشنهاد كرد كه بايد محاسبات را از دنياي ديجيتال وارد دنياي جديدي به نام كوانتوم كرد كه بسيار متفاوت از قبلي است و نه تنها مشكلات گذشته و محدوديت هاي موجود را بر طرف مي سازد، بلكه افق هاي جديدي را نيز به اين مجموعه اضافه مي كند. اين پيشنهاد تا اوايل دهه 90 ميلادي مورد توجه جدي قرار نگرفت تا بالاخره در 1994 «پيتر شور» از آزمايشگاه AT&T در آمريكا نخستين گام را براي محقق كردن اين آرزو برداشت. به اين ترتيب ارتباط نويني بين نظريه اطلاعات و مكانيك كوانتومي شروع به شكل گيري كرد كه امروز آنرا محاسبات كوانتومي يا محاسبات نانو متري (nano computing) مي ناميم. در واقع هدف محاسبات كوانتومي يافتن روشهايي براي طراحي مجدد ادوات شناخته شده محاسبات ( مانند گيت ها و ترانزيستورها ) به گونه ايست كه بتوانند تحت اثرات كوانتومي، كه در محدوده ابعاد نانو متري و كوچكتر بروز مي كنند، كار كنند. به نمودار صفحه بعد دقت كنيد.

         در اين شكل به طور شماتيك و در سمت چپ يك مدار نيم جمع كننده را مشاهده مي كنيد كه معادل كوانتومي و نانو متري آن در سمت راست پيشنهاد شده است. نوع اتم هاي به كار رفته، نحوه چينش اتم ها، چگونگي ايجاد سلول نمايش يافته ( معماري سلولي ) و چند ويژگي ديگر خصوصيات معادل با گيت هاي به كار رفته در نمونه ديجيتال هستند. يك راه نظري براي پياده سازي سلول در اين طرح، استفاده از «نقاط كوانتومي» (quantum dots) يا چيزي است كه در زبان مكانيك كوانتومي آنرا «اتم مصنوعي » مي ناميم.

 

         ورود به دنياي محاسبات كوانتومي نيازمند دو پيش زمينه مهم است. نخست بايد اصول اساسي و برخي تعابير مهم فلسفي مكانيك كوانتومي را به طور دقيق بررسي كرد. سپس مفهوم اطلاعات در فيزيك نيز، چه به صورت كلاسيك و چه در معناي جديد كوانتومي آن بايد درك شود.

 

Quantum Mechanics

        

         فيزيك كوانتومي مهم ترين دستاورد علم بشري در توصيف طبيعت است. اين نظريه كه در سالهاي 27-1925 توسط «ورنر هايزنبرگ»، «اروين شرودينگر»، «پل ديراك»، «ماكس پلانك» و چند تن ديگر پايه گذاري شد، اساس تمام ادراك امروزي ما از عالم است. به بيان دقيق تر، مكانيك كوانتومي مجموعه اي از قوانين، روابط رياضي و مفاهيم فلسفي است كه توصيف كننده رفتار ذرات بنيادين تشكيل دهنده عالم است. البته با تعميم همين قوانين و روابط، مي توان رفتار تمام سيستم هاي فيزيكي اي كه پيش از آن بررسي شده بودند را نيز بررسي و تعيين كرد. پايه رياضي اين نظريه جبر خطي عالي است. مفاهيمي از قبيل فضاي هيلبرت ، ماتريس ها، عملگرها، ويژه توابع و ويژه مقادير و تيديلات از مهم ترين موارد مي باشند. در حيطه فيزيك نظريه نيز مباحثي همچون تابع موج، سيستم و تحول آن، فضاي حالت، اندازه گيريها و مكانيك آماري مورد بررسي قرار مي گيرند. همچنين در سطوح بسيار پيشرفته تر و پيشروي اين نظريه عناويني همچون مفهوم و كاربرد اسپين، نظريه اندازه گيري، متغيرهاي پنهان، مساله ناجايگزيدگي، نيروي كوانتومي و ميدان راهنما، پارادوكس EPR  و قضيه بل مطرح مي شوند.

         معرفي مكانيك كوانتومي به عنوان يك ساختمان كاري فيزيكي جديد در ابتداي قرن بيستم منجر به تحولي عظيم در ساختار  چند هزار ساله انديشه بشري شد. مكانيك كوانتومي در ابتداي ظهورش بيشتر از آنكه به يك نظريه انقلابي شباهت داشته باشد به نوعي توجيه براي پاره اي بديهيات تجربي شباهت داشت كه با فيزيك كلاسيك قابل بيان نبودند. سه اثر مهم اين نظريه عبارتند از: 1) از ميان برداشتن جبر گرايي كه همواره اصلي ترديد ناپذير در فيزيك كلاسيك بود، 2) گسترش مفاهيم فيزيك درباره پديده هايي كه تا پيش از آن توجيهي براي آنها وجود نداشت مانند رفتار اتم ها، مولكولها و ذرات زير اتمي و 3) با آمدن مكانيك كوانتومي اين تصور بنيادي نهفته در تفكر بشري كه واقعيتي عيني وجود دارد كه وجودش متكي بر مشاهده شدنش نيست، زير سوال رفت.

         در فيزيك، اصولا هر نظريه اي متشكل از يكسري مجردات خاص است كه آن نظريه درباره آنها بحث مي كند. هر زير مجموعه از اين مجردات كه هدف خاصي را دنبال مي كند يك سيستم در آن نظريه ناميده مي شود. در مكانيك كوانتومي، تمام ذرات بنيادي، تمام مواد شناخته شده در عالم، تمام خصوصيات فيزيكي مانند ميدانها، دماها و ... جزو مجردات مي باشند. به عبارت ديگر اين نظريه را مي توان براي هر موجود فيزيكي ( در معناي عام ) با هر اندازه و نوع به كار برد. به عنوان مثالهايي از چند سيستم كوانتومي مي توان به اتم هيدروژن با هدف تعيين موقعيت آن در يك جعبه سه بعدي، دو الكترون در يك شتابدهنده با هدف تعيين نتيجه حاصل از برخورد پر انرژي شان، يك حجم ديفرانسيلي از پرتوهاي كيهاني با هدف تعيين تكانه زاويه اي و  دو اتم در هم تافته با هدف تعيين حالت اسپيني شان اشاره كرد.

 

Physical Meaning of Information

 

         براي آنكه بدانيم در فيزيك منظورمان از اطلاعات دقيقا چيست، چند تعبير نسبتا متفاوت را از اطلاعات بايد مد نظر داشت. اين تعابير عبارتد از: 1) اطلاعات در غالب يك الگو، 2) اطلاعات در شكل ورودي حسي، 3) اطلاعات به مثابه تاثيري كه منجر به يك تغير شود و 4) اطلاعات به عنوان پيام. تعبير پيام بودن اطلاعات به آنچه در محاسبات و اطلاعات كوانتومي مطرح مي شود بسيار نزديك است. پيام بودن مستلزم آن است كه فرستنده اي به گيرنده اي مرتبط شود كه مرتبط با بحث كانال هاي ارتباطي است. البته پارازيت ها را در اين گروه قرار نمي دهيم زيرا مانع از جريان ارتباط شده و باعث بروز سوء تعبير مي شوند. اگر به اطلاعات صرفا با ديد پيام نگريسته شود، اين پيام لزوما نبايد دقيق يا درست باشد. پس اطلاعات هر نوع پيامي است كه فرستنده براي ايجاد كردن انتخاب مي كند و البته آنرا از طريق خاصي مي فرستد. اگر اطلاعات را به صورت پيام هايي كه بين فرستنده و گيرنده منتقل مي شوند فرض كنيم آنگاه مي توانيم با معياري آنها را اندازه گيري كرده و بسنجيم. اندازه گيري اطلاعات در غالب پيام، نخستين بار در 1948 توسط " كلود شانن " در نظريه اطلاعات مطرح شد. به طور خلاصه وي پيشنهاد كرد كه اگر فرستنده اي از يك مجموعه شامل N پيام با احتمال مساوي يكي را براي فرستادن انتخاب كند، در اينصورت اندازه " اطلاعاتي كه با انتخاب يك پيام از مجموعه بوجود آمده " لگاريتم در مبناي 2 عدد N است. انتخاب پايه لگاريتمي مطابق است با انتخاب يك واحد براي اندازه گيري اطلاعات. اگر از لگاريتم در پايه 2 استفاده كنيم واحدهاي حاصل را ارقام دودويي يا به اختصار بيت مي ناميم.

         با ورود فيزيك به عرصه محاسبات و اطلاعات تعابير مطرح شده توسط شانن در غالب هايي فيزيكي قرار گرفتند. مهم ترين غالب به كار رفته داخل كردن مفهوم آنتروپي براي توليد نظريه اطلاعاتي جديد بود كه در آن از مكانيك آماري كوانتومي استفاده مي شود. مفهوم اساسي آنتروپي در نظريه اطلاعات در ارتباط با اين مطلب است كه يك سيگنال يا يك رخداد اتفاقي تا چه حد تصادفي است. به عبارت ديگر مي توان پرسيد كه يك سيگنال چه ميزان از اطلاعات را حمل مي كند. براي نمونه متني را به انگليسي در نظر بگيريد كه با دنباله اي از حروف، فضاهاي خالي و علائم نگارشي كد گذاري شده است ( بنابراين، سيگنال ما در اينجا رشته اي از حروف است ). چون نمي توانيم پيش بيني كنيم كه كاراكتر بعدي دقيقا چيست، اين رشته ( يا در واقع سيگنال ) كاتوره اي است. آنتروپي در واقع معياري از اين كاتورگي است. آنتروپي يك منبع اطلاعاتي به معناي تعداد ميانگين بيت ها به ازاي علامت لازم براي كد گذاري آنها است. البته توجه به دو نكته ضروري است: اول آنكه بسياري از بيت هاي داده اي ممكن است هيچ نوع اطلاعاتي را نرسانند و دوم اينكه مقدار آنتروپي هميشه عدد صحيحي از بيت ها نيست.

         با معرفي اطلاعات فيشر به عنوان تعبير نهايي فيزيكي اطلاعات، رهيافت به حداكثر رساندن اطلاعات فيزيكي از طريق تغيير دامنه احتمال سيستم، اصل اطلاعات فيزيكي فرين (EPI) در واقع ابزاري براي كشف قوانين خالص علم است. تا آنجا كه به فيزيك مربوط مي شود، قوانين طبيعي در غالب معادلات ديفرانسيل يا توابع توزيع آشكار مي شوند، مانند تابع موج شرودينگر يا تابع توزيع فرمي- ديراك. اصل EPI بر اين تفكر استوار است كه مشاهده يك پديده " منبعي " هرگز به طور كامل دقيق نيست. يعني اطلاعات به حتم در گذر از منبع تا مشاهده شدن، گم مي شوند. مقدار بيشينه در اغلب مشاهدات كمينه است !! يعني در مشاهداتي كه انجام مي دهيم همواره تلاش مي كنيم تا به حداكثر اطلاعات توصيف كننده ساختار مورد نظر دست پيدا كنيم. مفهوم معرفي شده در اين قسمت چكيده مختصري از مفهوم اطلاعات فيزيكي است. در نظريه اطلاعات كوانتومي، بسياري از اين موارد دستخوش تغيير مي شوند.

 

 

Classical Computation

 

         محاسبات بدون در نظر گرفتن نوع آن، دانشي است كه براي پردازش اطلاعات بوجود آمد. به عبارت دقيق تر، از اصول محاسبات براي پردازش اطلاعات استفاده مي كنيم و از نتيجه حاصل از آن براي برقراري ارتباط با ساير مجموعه هاي فيزيكي بهره مي گيريم. علاوه بر مباني رياضي، در دانش محاسبات، مدل هايي وجود دارند كه پردازش اطلاعات با استفاده از آنها توصيف مي شود. اساسي ترين مدل، مدل ماشين تورينگ است كه قبلا به آن اشاره شد. درك كامل اين مدل به عنوان سنگ بناي دانش اطلاعات اهميت به سزايي دارد. بر اساس همين ساختار نظري، مدل مداري بوجود آمد كه منطق دودويي را به صورت فيزيكي مورد استفاده قرار داد. اين مدل، اساس دانش محاسبات و الكترونيك ديجيتال امروزي است كه در آن از جبر سوئيچينگ كه اصلاح شده جبر بول دو ارزشي است استفاده مي شود. در نظريه مداري مي توان با چند جزء اساسي و اوليه، اعمال گوناگوني را روي واحدهاي اطلاعاتي انجام داد. در واقع يك فرآيند محاسبه اي، به صورت دنباله اي از اين اعمال در نظر گرفته مي شود كه روي رشته اي از واحدهاي اطلاعاتي اجرا مي شوند. علي رغم قدرت بالايي كه سيستمهاي محاسباتي مبتني بر مدل هاي مداري تا امروز بدست آورده اند، بايد خاطر نشان كرد كه هنوز هم در اين فضا مسائلي وجود دارند كه از اين نظر غير قابل حل بوده يا به عبارت بهتر حل و محاسبه آنها با در نظر گرفتن منابع زماني و انرژي، امكان پذير نيست. از اين رو در هر مدل محاسباتي همواره بايد درك كاملي نيز از منابع محاسباتي، كلاسهاي پيچيدگي و محاسبه پذيري داشت.

 

Quantum Computation

         كامپيوتر تنها بخشي از دنيايي است كه ما آنرا دنياي ديجيتالي مي ناميم. پردازش ماشيني اطلاعات، در هر شكلي، بر مبناي ديجيتال و محاسبات كلاسيك انجام مي شود. اما كمتر از يك دهه است كه روش بهتر و قدرتمندتر ديگري براي پردازش اطلاعات پيش رويمان قرار گرفته كه بر اساس مكانيك كوانتومي مي باشد. اين روش جديد با ويژگيهايي همراه است كه آنرا از محاسبات كلاسيك بسيار متمايز مي سازد. گرچه محاسبات دانشي است كه اساس تولد آن در رياضيات بود، اما كامپيوترها سيستم هايي فيزيكي هستند و فيزيك در آينده اين دانش نقش تعيين كننده اي خواهد داشت. البته وجود تفاوت بين اين دو به معناي حذف يكي و جايگزيني ديگري نيست. به قول «نيلس بور» گاهي ممكن است خلاف يك حقيقت انكار ناپذير منجر به حقيقت انكار ناپذير ديگري شود. بنابراين محاسبات كوانتومي را به عنوان يك زمينه و روش جديد و بسيار كارآمد مطرح مي كنيم. وجود چند پديده مهم كه مختص فيزيك كوانتومي است، آنرا از دنياي كلاسيك جدا مي سازد. اين پديد ه ها عبارتند از: بر هم نهي(superposition) ، تداخل (interference) ، Entanglement ، عدم موجبيت (non determinism) ، نا جايگزيدگي (non locality) و تكثير ناپذيري (non clonability) . براي بررسي اثرات اين پديده ها در اين روش جديد، لازم است كه ابتدا واحد اطلاعات كوانتومي را معرفي كنيم.

         هر سيستم محاسباتي داراي يك پايه اطلاعاتي است كه نماينده كوچكترين ميزان اطلاعات قابل نمايش، چه پردازش شده و چه خام است. در محاسبات كلاسيك اين واحد ساختاري را بيت مي ناميم كه گزيده واژه «عدد دودويي» است زيرا مي تواند تنها يكي از دو رقم مجاز صفر و يك را در خود نگه دارد. به عبارت ديگر هر يك از ارقام ياد شده در محاسبات كلاسيك، كوچكترين ميزان اطلاعات قابل نمايش محسوب مي شوند. پس سيستم هايي هم كه براي اين مدل وجود دارند بايد بتوانند به نوعي اين مفهوم را عرضه كنند. در محاسبات كوانتومي هم چنين پايه اي معرفي مي شود كه آنرا كيوبيت (qubit) يا بيت كوانتومي مي ناميم. اما اين تعريف كيوبيت نيست و بايد آنرا همراه با مفهوم و نمونه هاي واقعي و فيزيكي درك كرد. در ضمن فراموش نمي كنيم كه كيوبيت ها سيستم هايي فيزيكي هستند، نه مفاهيمي انتزاعي و اگر از رياضيات هم براي توصيف آنها كمك مي گيريم تنها بدليل ماهيت كوانتومي آنها است.

         در فيزيك كلاسيك براي نگه داري يك بيت از حالت يك سيستم فيزيكي استفاده مي شود. در سيستم هاي كلاسيكي اوليه ( كامپيوترهاي مكانيكي ) از موقعيت مكاني دندانه هاي چند چرخ دنده براي نمايش اطلاعات استفاده مي شد. از زمانيكه حساب دودويي براي محاسبات پيشنهاد شد، سيستم هاي دو حالتي انتخابهاي ممكن براي محاسبات عملي شدند. به اين معني كه تنها كافي بود تا سيستمي دو حالت يا دو پيكربندي مشخص، متمايز و بدون تغيير داشته باشد تا بتوان از آن براي اين منظور استفاده كرد. به همين جهت، از بين تمام كانديداها، سيستم هاي الكتريكي و الكترونيكي براي اين كار انتخاب شدند. به اين شكل، هر بيت، يك مدار الكتريكي است كه يا در آن جريان وجود دارد يا ندارد.

         هر بيت كوانتومي يا كيوبيت عبارت است از يك سيستم دودويي كه مي تواند دو حالت مجزا داشته باشد. به عبارت فني تر، كيوبيت يك سيستم دو بعدي كوانتومي با دو پايه به شكل  و  است. البته نمايش پايه ها يكتا نيست، به اين دليل كه بر خلاف محاسبات كلاسيك در محاسبات كوانتومي از چند سيستم كوانتومي به جاي يك سيستم ارجح استفاده مي كنيم. اولين كانديد براي نمايش كيوبيت استفاده از مفهوم اسپين است كه معمولا اتم هيدروژن براي آن به كار مي رود. در اندازه گيري اسپين يك الكترون، احتمال بدست آمدن دو نتيجه وجود دارد: يا اسپين رو به بالاست كه با آنرا با  نشان مي دهيم و معادل  است و يا رو به پائين است كه با  نشان مي دهيم و معادل است با |1>| . بالا يا پائين بودن جهت اسپين در يك اندازه گيري از آنجا ناشي مي شود كه اگر اسپين اندازه گيري شده در جهت محوري باشد كه اندازه گيري را در جهت آن انجام داده ايم، آنرا بالا و اگر در خلاف جهت اين محور باشد آنرا پائين مي ناميم. علاوه بر اسپين از وضع قطبش يك پرتو فوتوني و نيز سطوح انرژي مجزاي يك اتم دلخواه نيز مي توان به عنوان سيستم كيوبيتي استفاده كرد. شايد بتوان مهم ترين تفاوت بيت و كيوبيت را در اين دانست كه بيت كلاسيك فقط مي تواند در يكي از دو حالت ممكن خود قرار داشته باشد در حاليكه بيت كوانتومي مي تواند به طور بالقوه در بيش از دو حالت وجود داشته باشد. تفاوت ديگر در اينجاست كه هرگاه بخواهيم مي توانيم مقدار يك بيت را تعيين كنيم اما اينكار را در مورد يك كيوبيت نمي توان انجام داد. به زبان كوانتومي، يك كيوبيت را با عبارت  نشان مي دهيم. حاصل اندازه گيري روي يك كيوبيت حالت |o> را با احتمال C12 و حالت |1>| را با احتمال C22 بدست مي دهد. البته اندازه گيري يك كيوبيت حتما يكي از دو نتيجه ممكن را بدست مي دهد. از سوي ديگر اندازه گيري روي سيستم هاي كوانتومي حالت اصلي آنها را تغيير مي دهد. كيوبيت در حالت كلي در يك حالت بر هم نهاده از دو پايه ممكن قرار دارد. اما در اثر اندازه گيري حتما به يكي از پايه ها برگشت مي كند. به اين ترتيب هر كيوبيت، پيش از اندازه گيري شدن مي تواند اطلاعات زيادي را در خود داشته باشد.

         بر اساس اصل برهم نهي، هر سيستم كوانتومي كه بيش از يك حالت قابل دسترس دارد، مي تواند به طور همزمان در يك تركيب خاص از آن حالت ها هم قرار داشته باشد. در اصطلاح مي گوئيم كه سيستم كوانتومي علاوه بر حالت هاي ناب يك يا چند حالت آميخته يا بر هم نهيده (blend or superposed) نيز دارد. پس اگر يك ساختار حافظه اي n كيوبيتي داشته باشيم، طبق اين اصل، اين تعداد مي توانند در پيكربندي متمايز وجود داشته باشند. به اين ترتيب يك كامپيوتر كوانتومي اين امكان را      مي يابد كه مانند يك كامپيوتر موازي كلاسيك بسيار پر قدرت عمل كند كه در يك لحظه روي چندين مسير اطلاعاتي پردازش مي كند. البته مشاهده و متمايز كردن تك تك اين محاسبه گرهاي كوانتومي غير ممكن است. چون كامپيوتر كوانتومي با تعداد بسيار زيادي مسير محاسباتي كار مي كند، مي توان كاري كرد كه اين محاسبات با هم تداخل يا بر هم تاثير هم داشته باشند. به عبارتي، محاسباتي كه به طور موازي با هم انجام مي شوند طبق اصل تداخل مي توانند اثر هم را تقويت يا تضعيف كنند. در نتيجه محاسبه اي شبكه اي بوجود مي آيد كه نوعي خاصيت جمعي از تمام محاسبات را نشان مي دهد. خاصيت بسيار شگفت انگيز در مكانيك كوانتومي خاصيت در هم تافتگي است. اگر دو يا چند كيوبيت را در بر هم كنش با هم قرار دهيم، مي توانند براي مدتي در يك حالت كوانتومي مشترك قرار بگيرند به طوريكه نتوان آن حالت را به شكل حاصلضربي از حالت هاي جدا از هم اوليه نشان داد. حالت اين واحدهاي اطلاعاتي را گنگ يا نادقيق (fuzzy) مي ناميم. يك نتيجه مهم entanglement اين است كه يك جفت كيوبيت در هم پيچيده روي يكديگر تاثير همزماني را مي گذارند كه به فاصله آنها از يكديگر و ماده اي كه اين فاصله را پر مي كند بستگي ندارد. يك جفت در هم تافته با هم مخلوط نمي شوند بلكه تنها به طور كوانتومي با هم بر هم كنش مي كنند.

Physical Implementation

 

         نسل اول ماشين هاي محاسبه گر اينچنيني، در واقع تماما كوانتومي نيستند. به اين معني كه تنها سعي شده است تا بخش سخت افزاري آنها بتواند در مقياس نانو و با تكيه بر مكانيك كوانتومي عمل كند. اما الگوريتم ها يا همان نرم افزارهايي كه اين كامپيوترها اجرا مي كنند، كماكان كلاسيكي هستند. از اين رو آنها را «كامپيوترهاي كلاسيكي در مقياس نانو» مي نامند. اما از آغاز قرن جديد، هدف فيزيكدانان طراحي الگوريتم هاي كوانتومي و مطابقت دادن آنها با سيستم هاي سخت افزاري پيشنهادي است تا به يك كامپيوتر كوانتومي واقعي برسند.

 

در سمت چپ تصوير فوق يك ترانزيستور تك الكتروني (SET) و در سمت راست عنصر محاسباتي كوانتومي يعني يك مولكول قرار دارد. مولكول فوق مربوط به كلروفرم به فرمول  است. اين مولكول ( كه در آن از اتم كربن 13 استفاده مي شود ) مانند يك آهن رباي كوچك عمل مي كند كه مي تواند با ميدانهاي مغناطيسي خارجي بر هم كنش داشته باشد. اسپين هاي هسته اي منابع ذخيره و پردازش اطلاعات هستند.

         قرن نوزدهم به قرن ماشين معروف شد. قرن بيستم نيز قرن روشهاي پردازش اطلاعات شد. اما بي شك بايد قرن بيست و يكم را صده مهندسي كوانتومي ناميد. همان طور كه ظهور مكانيك كوانتومي در يكصد سال پيش، مكانيك نيوتني را نقض نكرد بلكه آنرا تكميل تر كرد، ظهور كامپيوترهاي كوانتومي نيز به معني كنار گذاشتن محاسبات كلاسيك نيست. هدف دانشمندان تنها يافتن روشي براي بدست آوردن پرسش هاي بنيادين خود درباره طبيعت و نحوه عملكرد آن است. پس طبيعي است كه در اختيار داشتن يك ابزار محاسباتي بسيار سريع و كارآمد تا چه حد مي تواند در اين امر ياري رسان باشد. محاسبات و اطلاعات كوانتومي زمينه اي بسيار پيشرفته و نوپا در فيزيك است كه گرچه حركت آن در مقايسه با ساير زمينه ها هنوز كند است اما در مدت كمتر از 10 سال از يك به اصطلاح تئوري محض كه هيچ اميدي به محقق شدن آن نمي رفت، امروز به يك فرآورده عملي تبديل شده و به سرعت در حال پيشروي است. مراكز تحقيقاتي بزرگي در اروپا و آمريكاي شمالي از جمله انيستيتو پريميتر در كانادا، شركت IBM ، دانشگاههايي همچون آكسفورد، MIT ، هاروارد، پرينستون و چندين مركز ديگر به طور جدي روي اين موضوع مشغول تحقيق هستند. هنر فيزيك، تغيير نگرش بشر به عالم پيرامون و توصيف پديده هايي است كه مدتها برايمان جزو اسرار بودند. امروز اعتقاد داريم كه عالم در غالب يك كل، خود يك كامپيوتر كوانتومي است. اما اين ماشين چطور كار مي كند؟ برنامه ريزي و هدايت آن چطور صورت مي گيرد؟ و اينكه اصلا هدف از اين همه محاسبه چيست؟ چيستي عالم محاسباتي، همان غايت نظر فيزيكدانان است، اينكه از كجا آمده ايم و به كجا مي رويم. شايد روزي پس از عقبگرد عالم به نزديكي روزگار نخستينش، در آن انقباض دور از ذهن، در «نقطه امگا» پاسخ تمام پرسش هايمان را بيابيم.

 

Maysam Tehrani

منبع : http://www.nano.ir/paper.php?PaperCode=236

 

 |+| نوشته شده در  جمعه دوم فروردین 1387ساعت 9:55 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام

 


مثل ماهي زنده
مثل سبزه زيبا
مثل سمنو شيرين
مثل سنبل خوشب
و مثل سيب خوش رنگ
و مثل سکه با ارزش باشيد
سال نو مبارک

 

 |+| نوشته شده در  پنجشنبه یکم فروردین 1387ساعت 10:46 قبل از ظهر  توسط حامد سلیمی پور  |  داغ کن - کلوب دات کام
 
  بالا