Pinned Repositories
Business-Cards-Graphic
This repository contains different business cards that I design them with Photoshop and illustrator softwares.
ContactMe
This repository contains simple code for contact links.
Infographic-graphic
This repository contains ...
Logos-Graphic
This repository has thirty six logo that is designed and created with illustrator and photoshop softwares.
machine-learning-projects
this repository contains different machine learning projects and different python packages like pandas, numpy, scikit-learn, scipy and so on are used in.
RAFT-Leader-Election-Distributed-Systems
Raft Overview: The Raft protocol is used to manage replica servers for services that must continue operation in the face of failure (e.g. server crashes, broken or flaky networks). The challenge is that, in the face of these failures, the replicas won't always hold identical data. The Raft protocol helps sort out what the correct data is. Raft's basic approach for this is to implement a replicated state machine. Raft organizes client requests into a sequence, called the log, and ensures that all the replicas agree on the the contents of the log. Each replica executes the client requests in the log in the order they appear in the log, applying those requests to the service's state. Since all the live replicas see the same log contents, they all execute the same requests in the same order, and thus continue to have identical service state. If a server fails but later recovers, Raft takes care of bringing its log up to date. Raft will continue to operate as long as at least a majority of the servers are alive and can talk to each other. If there is no such majority, Raft will make no progress, but will pick up where it left off as soon as a majority is alive again. every server can have one of the three following roles in every moment: 1) It can be leader who receive client's requests and reply them and should do replication log. 2) It can be follower who put in the log every thing that receive and execute them.3) It can be candidate who take part in leader election to get majority votes. to run it, you should start from "make()" function, in this function after initialize some variables, check if should start leader election or not respect to weather receive RPC (or heartbeat) from Leader/Candidate or not. in make() in "weatherDo()" check the time which last heart beat from leader received, and compare this time with threshold and decide to start election or not , it assign random times to servers not to have the problem of two leaders in one time in election. when each server start up, it start from "follower" state, so server state is initialize with "follower". a server stay on follower state until receive valid RPC from a leader or candidate. leaders send heartbeat to all followers alternatively to save it's originality. heartbeat is an "append entries RPC" without any log entry. to do that i use channels in Go. leader make channel for others and append this channels to each other and call "Send Heartbeat" function. if a follower in a special time period receive no communication, then it call Election Timeout and suppose there is no reliable leader in system so it start an election to chose new leader. to start an election the follower increase last term one unit by calling "Set Term" and change it's state to "candidate" state. and vote itself and then send "Request Vote RPC" to every servers in cluster in parallel. "majority voters" variable is defined to check weather it get majority vote or "split votes" is happened! a candidate stay on it's state until on of 3 events happened: 1-it win in a election or, 2-another server say"hello, I am leader:)" or, 3-a time period finished but no servers become leader. each server in each term can vote to one candidate in maximum! if there is no vote before the "vote for" variable has -1 as value. when the candidate wait for votes, it may receive "Append Entry RPC" from other server who claim is leader. if leader term in RPC is big like candidate term, it means this claim is true so the candidate return to "follower" state , other wise ,Current candidate reject the RPC with put false in "Reply success" variable and it means one of last leaders who was crashed now start up with lower term so current candidate stay on it's state. to test it just type: go test -run election .
shoppingCart
Shopping cart is an online shoes shop which you can add your selected items to card or remove them. products come from different javascript file so can easily used for shops with other products.
tapsi-demo
Tapsi is a Internet Taxi. This website is developed from it's Figma file in detail and it is responsive for tablet size or mobile size screen too.
ToDoList
This repository is to-do-list. It is created using HTML, CSS, Javascript. You can add new task, Remove tasks or Mark tasks as done or important. You can use to-do-list to manage your tasks every day.
Fatemeh-sadat-Torabi's Repositories
Fatemeh-sadat-Torabi/Business-Cards-Graphic
This repository contains different business cards that I design them with Photoshop and illustrator softwares.
Fatemeh-sadat-Torabi/ContactMe
This repository contains simple code for contact links.
Fatemeh-sadat-Torabi/Infographic-graphic
This repository contains ...
Fatemeh-sadat-Torabi/Logos-Graphic
This repository has thirty six logo that is designed and created with illustrator and photoshop softwares.
Fatemeh-sadat-Torabi/machine-learning-projects
this repository contains different machine learning projects and different python packages like pandas, numpy, scikit-learn, scipy and so on are used in.
Fatemeh-sadat-Torabi/RAFT-Leader-Election-Distributed-Systems
Raft Overview: The Raft protocol is used to manage replica servers for services that must continue operation in the face of failure (e.g. server crashes, broken or flaky networks). The challenge is that, in the face of these failures, the replicas won't always hold identical data. The Raft protocol helps sort out what the correct data is. Raft's basic approach for this is to implement a replicated state machine. Raft organizes client requests into a sequence, called the log, and ensures that all the replicas agree on the the contents of the log. Each replica executes the client requests in the log in the order they appear in the log, applying those requests to the service's state. Since all the live replicas see the same log contents, they all execute the same requests in the same order, and thus continue to have identical service state. If a server fails but later recovers, Raft takes care of bringing its log up to date. Raft will continue to operate as long as at least a majority of the servers are alive and can talk to each other. If there is no such majority, Raft will make no progress, but will pick up where it left off as soon as a majority is alive again. every server can have one of the three following roles in every moment: 1) It can be leader who receive client's requests and reply them and should do replication log. 2) It can be follower who put in the log every thing that receive and execute them.3) It can be candidate who take part in leader election to get majority votes. to run it, you should start from "make()" function, in this function after initialize some variables, check if should start leader election or not respect to weather receive RPC (or heartbeat) from Leader/Candidate or not. in make() in "weatherDo()" check the time which last heart beat from leader received, and compare this time with threshold and decide to start election or not , it assign random times to servers not to have the problem of two leaders in one time in election. when each server start up, it start from "follower" state, so server state is initialize with "follower". a server stay on follower state until receive valid RPC from a leader or candidate. leaders send heartbeat to all followers alternatively to save it's originality. heartbeat is an "append entries RPC" without any log entry. to do that i use channels in Go. leader make channel for others and append this channels to each other and call "Send Heartbeat" function. if a follower in a special time period receive no communication, then it call Election Timeout and suppose there is no reliable leader in system so it start an election to chose new leader. to start an election the follower increase last term one unit by calling "Set Term" and change it's state to "candidate" state. and vote itself and then send "Request Vote RPC" to every servers in cluster in parallel. "majority voters" variable is defined to check weather it get majority vote or "split votes" is happened! a candidate stay on it's state until on of 3 events happened: 1-it win in a election or, 2-another server say"hello, I am leader:)" or, 3-a time period finished but no servers become leader. each server in each term can vote to one candidate in maximum! if there is no vote before the "vote for" variable has -1 as value. when the candidate wait for votes, it may receive "Append Entry RPC" from other server who claim is leader. if leader term in RPC is big like candidate term, it means this claim is true so the candidate return to "follower" state , other wise ,Current candidate reject the RPC with put false in "Reply success" variable and it means one of last leaders who was crashed now start up with lower term so current candidate stay on it's state. to test it just type: go test -run election .
Fatemeh-sadat-Torabi/shoppingCart
Shopping cart is an online shoes shop which you can add your selected items to card or remove them. products come from different javascript file so can easily used for shops with other products.
Fatemeh-sadat-Torabi/tapsi-demo
Tapsi is a Internet Taxi. This website is developed from it's Figma file in detail and it is responsive for tablet size or mobile size screen too.
Fatemeh-sadat-Torabi/ToDoList
This repository is to-do-list. It is created using HTML, CSS, Javascript. You can add new task, Remove tasks or Mark tasks as done or important. You can use to-do-list to manage your tasks every day.