\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={An Agent-based Grouping Strategy for Federated Grid Computing},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2018-01-15 (revised: 15 January 2018)}
\def\TheID{\makeatother }
\def\TheDate{2018-01-15}
\title{An Agent-based Grouping Strategy for Federated Grid Computing}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Md. Tanvir  Rahman}

             \author[2]{Aminul  Haque}

\renewcommand\Authands{ and }

\date{\small \em Received: 11 December 2017 Accepted: 1 January 2018 Published: 15 January 2018}

\maketitle


\begin{abstract}
        


Characterizing users based on their requirements and forming groups among providers accordingly to deliver them the stronger quality of service is a challenge for federated grid community. Federated grid computing allows providers to behave cooperatively to ensure required utility by users. Grouping grid providers under such an environment thus enhance the possibility of more jobs executed whereas a single provider or organization might not be able to do the same. In this paper, we propose an agent-based iterative Contract Net Protocol which supports in building federated grid via negotiating distributed providers. The main focus of this paper is to minimize the number of iterations using a grouping mechanism. Minimizing the number of iterations would produce less communication overhead which results in the minimum queue waiting time for users to publish their jobs. Simulation results further ensure the feasibility of our approach in terms of profit and resource utilization compared to that of the traditional non-grouped market.

\end{abstract}


\keywords{grid computing, agent technology, economic model, group formation.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
rid computing is a special kind of network that connects distributed computer resources (such as clusters, supercomputers, and datasets) to provide stronger computation power as well as data warehouse over the Internet in order to solve computationally intensive problems (such as drug design, investigate material properties and weather forecasting). These resources are typically owned by different owners and driven by different rules and policies. Economic models such as Contract Net Protocol (CNP) \hyperref[b0]{[1]}, Double Auction \hyperref[b1]{[2]}, and Commodity market \hyperref[b2]{[3]} are found suitable in harnessing these distributed resources over different ownership. Recently federated grid has emerged as a new approach that supports coordination of resources through grouping mechanism in order to optimize users quality of service (QoS) (i.e. resource availability, reliability, performance etc.) \hyperref[b3]{[4]}, \hyperref[b4]{[5]}. However, autonomous coordination of distributed resources is essential to achieve perceived utility by users. However, extreme heterogeneity, dynamic nature, and different ownership of these resources impose challenges to do that.\par
Agent technology in computer science is well known due to their autonomous actions in making decisions and capability of interacting (such as cooperate, coordinate and negotiate) with other agents like other social beings. Due to the development and application of agent technologies, a surge of interest has been focused on agent-oriented methodologies and modeling techniques. The reason for including agents in grid computing is that grid computing and agent systems have similar objectives. Both aim to achieve "large-scale open distributed systems, capable to effectively and dynamically deploy and redeploy resources as required, to solve computationally complex problems" \hyperref[b5]{[6]}. Similarly, agents representing different grid providers can interact with each other and form groups or teams in order to meet their respective goals (e.g. meeting users QoS, earning profit etc.). However, differentiating among QoS (i.e. typically represented by user's preference values on QoS), and forming groups accordingly to meet their demands are open issues in this field.\par
In this paper, we study how to characterize different users in terms of their varied utility demands and budget constraints. Perceive different utility is important in order to deliver stronger QoS. In addition, we study how to map appropriate groups with received users to enhance system efficiency (e.g. better profit and resource utilization). We propose an agent-based iterated CNP (iCNP) where agents representing users and providers are autonomous to interacting each other and both appear with their respective requests and offers. iCNP allows multi-round iterative bidding. In general, under such an economic model, a manager (user) issues/publish the initial call for proposal (cfp)/ resource demand. The contractors (providers) then evaluate the proposal and propose their bids. The manager then accepts one or more of the bids or may iterate the process by issuing a revised cfp. However, escaping from one round and then waiting for the next round to resubmit the request may cause a long queue waiting time in a large-scale framework which is typically comprised of thousands of users and providers such as grid. Hence, in this paper, we further focus on how to treat a user in a better way from the first round by incorporating grouping mechanism and thus to minimize the number of iterations. Minimize the number of iterations prevents users from the uncertainty to best treat their values and reduces communication delay dramatically since negotiation with users as well as G II. 
\section[{Related Work}]{Related Work}\par
Chao et al. \hyperref[b3]{[4]} proposed for grouping grid nodes in terms of nodes' own desires to optimize resource allocation problem. They grouped-up according to compatible users and providers based on catallaxy-based market though how they defined different criteria to do this is not clear. In addition, they conducted the simulation with 100 agents (50 users and 50 providers) but what impact it would have if they conducted the simulation with varying the number of users and providers is not taken into account. We conduct our simulation with thousands of users and a varying number of users and providers.\par
CNP has been used in a cluster environment to optimize utility for users \hyperref[b0]{[1]}. They have compared the performance of CNP and traditional Round Robin Protocol (RRP) in terms of different job arrival rates and show the advancement of CNP over RRP in terms of utility and computational cost. They have conducted their simulation by incorporating two scenarios; firstly, the scenario that accommodates all the mono-thematic applications (similar kind of applications) and secondly, which accommodates heterogeneous tasks. However, in our work, we focus on iCNP and characterize users in terms of their preferences, such that they can be efficiently evaluated.\par
Goswami adopts \hyperref[b6]{[7]} CNP to deal with resource heterogeneity and proposes two resource selection policies. One is K-time optimization policy, in which users are sorted in ascending order in terms of their proposed deadlines of finishing their jobs. Another one is, K-cost optimization policy, in which users are sorted in terms of their budgets, they are willing to pay. The value of K refers to whether to switch from K-time to Kcost or not and vice versa. The drawback of this system is, though the failed users have the chance to reannounce/revise their cfp, they still resubmit their cfp without changing anything (e.g. increase budget or reduce QoS). Hence, the probability of accepting revised cfp would be decreasing and produce high communication overhead. We change cfp over iterations which maximize to successful SLA establishment in each round.\par
An agent-based Content Distributed Grid (CDG) is proposed to form VOs \hyperref[b4]{[5]}. The concept of CDG is borrowed from Content Distributed Network (CDN) in where all the servers are co-operative to each other and belong to the same organization. The CDG is different to the point that all the resources under grid computing are competitive and belong to different owners. Hence, they propose an economic approach to motivate grid providers such that they can be cooperative in contributing their resources in order to maximize utility for users. The failed users can re-negotiate with providers based on their revised cfp and this can happen over a certain number of iterations. However, under which condition how many iterations it may have to allow users re-negotiate is not discussed. If the number of iterations is very low, some users might lose their chance to re-negotiate or if it is very high, it might produce high communication delay. We allow the auction to be continued until there are at least one potential user and one potential provider in the market which guarantees all the users making deal with providers. In addition, our grouping strategy helped to minimize iterations while ensuring best treat the users.\par
Ranjan et al. \hyperref[b7]{[8]} proposed CNP-based negotiation for meta-scheduling resources in federated grids. Their proposed SLA-based approach is designed to satisfy users by maintaining their job deadlines as well as allows providers to control over their resources. Users in their system are allowed to iterate the negotiation process if they fail in a particular round. However, how users revise their cfps is not discussed. Hence, accepting revised cfp becomes harder, since the providers keep the resource cost constant throughout an experiment. There could be another way of revising cfp, that is, minimizing resource requirements rather than maximizing budget but it may not be applicable to a group of users who define a resource as their optimization. Our group-based optimization strategy minimized the occurring of revising cfp and thus decreased the chance of generating such unexpected scenarios.\par
An enhanced ant colony algorithm combining the technique of Ant Colony System and Mix Ant System for job scheduling for grid computing is proposed in \hyperref[b8]{[9]}. The proposed algorithm also contains the concept of agent for the purpose of updating the grid resource table.\par
Laizhi Wei et al. \hyperref[b9]{[10]} proposed an improved ant algorithm for Grid task scheduling strategy with a new sort of pheromone and node distribution selection rule. The proposed algorithm can measure the performance of resources and tag on it. By dealing with the unsuccessful situations of task scheduling, unnecessary overhead of the system is reduced that results in shortening the total time requirement of a complete task. Sonal Yadav et al. \hyperref[b10]{[11]} proposed a cost based job grouping and scheduling algorithm that will be beneficial to both user and resource broker. Before allocating resources the algorithms groups the users job which results improved communication to computation ratio and utilization of available resources.\par
among providers requires huge communication process. We group providers based on their resource The authors of \hyperref[b11]{[12]} have proposed a grouping based job scheduling algorithm that uses priority queue and hybrid algorithm to maximize the resource utilization Year 2 018 
\section[{( ) E}]{( ) E}\par
© 2018 Global Journals and minimize processing time of the jobs. By considering static restrictions and dynamic parameters of jobs and machines the algorithm selects the best suitable machine for user's job. 
\section[{III.}]{III.} 
\section[{System Model}]{System Model}\par
We model our framework (Figure \hyperref[fig_0]{1}) with three types of agents, which are user-agent, provider-agent and traffic-agent. Each type of agents is programmed in a way so that it can try its maximum to reach an agreement (Service Level Agreement) while interacting with other agents. We use iCNP as the interaction protocol. Since it is iterative, agents in our model can optimize their goals through renegotiation. Details on iCNP are described in the following section. The three types of agents in our system try to reach the following individual goal: Type 1 (User-agents): Try to optimize the preferred values (e.g. storage, budget) as defined by the corresponding users, Type 2 (Provider-agent):Aims to receive more users so that they can maximize their profit, Type 3 (Traffic-agent): Is designed to receive and evaluate users' request and finally switch to the appropriate groups.\par
Therefore, it is clear that each type of agents has its own task to accomplish. However, in this work, we only consider users requests (jobs) as tasks. Such a task-oriented domain can be defined as, 
\section[{<T, A, C>}]{<T, A, C>}\par
Where T refers to the set of all tasks. Here the number of tasks (subsets) is equal to the number of users.\par
A=(\{A 1 ,?,A u \}, \{A 1 ,?,A p \}, A t ) is the set of participating agents. Au, Ap, and At refer the user-agent, provider-agent and traffic agent. Again, A u ? A, A p ? A, and t are always 1. C refers to the cost of executing a particular task. Now, we describe different types of agents in terms of their activity. 
\section[{a) User-Agent}]{a) User-Agent}\par
In our model, a user-agent is represented by A u where â?"?uâ?"?> 0 and can be any arbitrary number. Each A u is set by a few resource requirements, budget, deadline, and preferred optimization. This is called "call for proposal (cfp)" and given by,cfp u = \{R, B, D, Pref\}\par
However, in this work, we set an A u only with resource requirements (storage and processors) R, budget B and preferred value Pref. The preferred value can be either in resources or budget. The role of an A u is to try optimizing its Pref while considering other associated constraints. Hence, an A u can easily be characterized based on its cfp u . User-characterization is mandatory to deliver stronger service. In our work, we consider four different ways to differentiate users. Firstly, the users set processing as their preferences. In addition, respective budgets are relaxed, that is, willingly to pay whatever price providers impose on cfp. An A u can perceive its preference value automatically based on resource requirements. Hence, a cfp u can be re-written as, cfp u = \{CPUs ? predefined CPUs and storage < predefined storage, B(relaxed), D, CPU\} Secondly, the users set storage as their preferences. In this case, the budgets are relaxed as well. Similarly, an Au can perceive its optimization entity by using the following cfp u , cfp u = \{CPUs < predefined CPUs and storage ? predefined storage, B(relaxed), D, storage\} Thirdly, the users come with cost optimization. This is recognized by the following cfp u , cfp u = \{CPUs < predefined CPUs and storage < predefined storage, B, D, cost\} Finally, the users set combined optimization as their preferences, which means, they want more resources with lower costs. This type of cfp u can be defined as,cfp u = 
\section[{\{CPUs ? predefined CPUs and storage ? predefined storage, B, D, combined\}}]{\{CPUs ? predefined CPUs and storage ? predefined storage, B, D, combined\}}\par
Characterizing users in terms of their cfp would help grid providers to treat them better than might otherwise be expected. However, this characterization can be extended in a few more ways (such as both of resources optimization with relaxed budget). We have left either ways for our future work. We use different ranges for different resource requirements in order to dynamically set thousands of users. The average values of the ranges are considered as predefined resources. Please note that if an Au fails in a particular iteration, it revises its cfp u for the following iteration by increasing its budget until the budget reaches its maximum value. The next step of an Au is interacting with traffic-agent. 
\section[{b) Traffic-Agent}]{b) Traffic-Agent}\par
A traffic-agent is represented by A t . Only one A t is designed to deal with all A u. At first, it receives cfp u from an A u . Then it evaluates the cfp u and detects the preference value. After that, it evaluates appropriate group in order to better serve the user. Details on grouping are described in Section 2.3. Finally, it switches the A u to the appropriate group which is designed to treat the user best. Hence, it is crucial for an A t to determine appropriate groups of users otherwise it may cause some extra iterations which ultimately increases communication overhead. 
\section[{c) Provider-Agent}]{c) Provider-Agent}\par
A provider-agent is represented by A p . Where, â?"?pâ?"?> 0 and can be any arbitrary number. An A p is designed with resource availability and prices for the unit amount of resource consumption. Details on pricing are explained in the Economic model section. In this paper, we focus on the provider side. Therefore, we concentrate on provider strategy rather than user strategy. Although providers in grid computing are known to be self-interested, they can save costs by coordinating their activities among themselves. In a multi-agent paradigm, such a grouping activity is known as characteristic function game (CFG). In such games, the value of each group G is given by a characteristic function v G . Hence, providers can be grouped in several possible ways based on v G . This is called group structure (GS). So, for any group, we can say G ? GS.\par
We assume that providers are aware of the demand curve (a market trend on resource demand) and all available cases users can be characterized on. Based on this, all the providers under our federated grid automatically form into four different groups based on their resource availability. Groups are presented here in terms of their set of characteristic functions: v G =1: \{processors ? predefined processors and disk-space < predefined disk-space\} v G =2: \{processors < predefined processors and disk-space ? predefined disk-space\} v G =3: \{processors < predefined processors and disk-space < predefined disk-space\} v G =4: \{processors ? predefined processors and disk-space ? predefined disk-space\} Here, each G is formed to better treat its corresponding cfp u . For example, G1 (group1) is designed with that provider who are able to supply more processing power and thus to deliver stronger quality to type1 cfp u . However, grouping in our model occurs prior to serving a particular cfp u rather than after receiving the cfp u . The reason for this is to prevent users from waiting while forming groups over distributed domains. In addition, this would increase the probability of receiving more users by a particular G.\par
For each G, there is a group correspondent (typically the first provider), who initiates dealing with a cfp u and negotiates with other providers within that G if requires. However, G formation in any CFG needs to satisfy the following facts; Group structure generation: Formation of groups by the agents such that agents within each group coordinate their activities, but agents do not coordinate between groups. Typically, this generation occurs superadditively, which is, any G of agents is best off by Year 2 018 
\section[{( ) E}]{( ) E}\par
© 2018 Global Journals merging into one. This can be explained in terms of the utility function,UtilityA1?A2 ? UtilityA1 + UtilityA2\par
For all disjoint agents A1, A2 ? A. The utility function of an agent A for a deal ? in order to accomplish a task T can be defined as,UtilityA (?) = C (TA) -costA (?)\par
Where C (TA) refers to the cost originally assigned to the agent A to accomplish the task T and costA (?) is the cost spends to process the deal. The agents presented here are all A p and the utility function is restricted to G generation.\par
However, in many cases, G formation may not be super-additive since there are some costs (such as communication cost, security cost) to G formation process itself. Therefore, under costly computation, component grouping within a single provider or organization may be better off by not forming a composite grouping with different providers. However, in case of grid computing, most cases, a single provider is not able to meet large-scale resource requirements. Again, due to large-scale resources trading, associated costs would be less in most cases. Optimization of the group: Here, a particular G's objective is to maximize monetary value, that is, to maximize the utility value in combination. This can be achieved by increasing the money received from users or decreasing the cost of using resources. Payoff division: It divides the generated solution among the provider-agents of a particular G. The division should be in a fair and stable way so that the agents are motivated to stay with the G rather than move out of it. In our model, the solution of a particular G is divided into the providers according to the number of resources they have shared.\par
i. Group migration Though each cfp u is supposed to receive in its respective G which is appropriate to treat that cfp u , the corresponding A u can still be migrated to another G, if the designed G becomes unable to deliver the resource demands. Under a federated grid, this migration policy would increase the system efficiency, since it tries its maximum to treat a user well. However, there are some restrictions to migrate a cfp u from one G to another. As aforementioned, we are focusing on provider side; hence, we have used some strategies over migration so that the system can produce a better payoff.\par
Please note that all strategies of migrating a cfp u from one G to another is subject to unavailable resources with the G it is migrating from. Strategy 1: From providers' point of view, G1 and G2 users receive priority than others, since these users come with a relaxed budget. Hence, G1 and G2 users are allowed migrate to G3 and G4 at any iteration while iCNP. Strategy 2: G3 and G4 users are allowed migrate to G1 and G2 at all iterations except the first since the budgets of G3 and G4 users are not relaxed and thus get less priority by providers. This is done such that in the first iteration providers can receive more users with relaxed budget and thus to maximize profit.\par
However, our model supports to define a migration policy by a particular group G in either way about when to migrate and migrate to which. 
\section[{IV.}]{IV.} 
\section[{Implementation}]{Implementation}\par
We established a simulation environment and implemented the proposed model using a crossplatform multi-agent programmable modeling environment known as Netlogo \hyperref[b12]{[13]}, \hyperref[b13]{[14]}. We choose Netlogo because:\par
? Netlogo is a FIFA (Foundation for Intelligent Physical Agent) conformant platform \hyperref[b14]{[15]}.  We implemented FIFA conformant iCNP (Iterated Contract Net Protocol) which is an extension of the basic CNP, but it differs by allowing multi-round iterative bidding \hyperref[b15]{[16]}. iCNP supports optimizing a particular user's request by negotiating distributed providers. In such a model (Figure \hyperref[fig_1]{2}) a user is called a manager who issues an initial cfp. Providers are known as contractors, who then response with their bids and the manager may then accept one or more of the bids, the others, or may iterate the process by issuing a revised cfp. However, the number of iterations can be based on a time period or potential users (who can still maximize their budgets) and providers (who can still serve at least one standard user). We consider that the iteration continues until there are a potential user and a potential group. Though using our approach seems to increase number of iterations and thus communication overhead, the approach is more consistent in grid perspective and using our grouping strategy, number of iterations could be decreased. In our case, a group G receives a cfp via the traffic-agent (A t ) with the guarantee that the group G receives the correct cfp. However, evaluating a particular cfp would be different, if a particular group G receives the cfp from another group G (migration) rather than the traffic-agent (A t ). 
\section[{b) Bidding policy}]{b) Bidding policy}\par
In our system, each user comes with a band of budgets, which are minimum budget and maximum budget the user is willing to pay. Typically, an A u (useragent) corresponding to a user starts bidding from its minimum budget to the maximum budget over iterations if it can establish the SLA. The bidding in our mechanism follows linear increment. Though we are not focusing on user-strategy, we would like to change userbid over iterations rather than linearly in future. If an A u is unable to establish its SLA even after reaching its maximum budget, it will be considered as a failed job. Resources requested by an A u are priced by A p (provider-agent) using the unit price of each particular resource. These unit prices do not change over iterations. However, in future, we would like to change the prices based on supply and demand. The cost C of a task, T requested by a particular A u can be formalized as follows:\par
Where m refers to the resource type requested by A u . Typically, this can be storage, CPU, and memory. However, we conduct our simulation only with storage and CPU. n is the total number of resource types, Req m means required resource amount of type m P m is the unit price (e.g. price/GB storage) for type m. This is a function of a particular provider A p  
\section[{c) Optimize user-defined preferences in the groupbased federated grid}]{c) Optimize user-defined preferences in the groupbased federated grid}\par
In our implementation, we distinguished userdefined preferences in two ways. One is resource optimization which includes optimization for storage and CPU and another one is budget optimization. As we are using group-based strategy, it is easier to optimize a particular resource type, since typically a group only receives cfp with those preferences which the group is specialized for. For example, if a user's preference is storage, he goes under group 2, since the group is comprised of those providers who have more storage power. Therefore, the optimization of a particular resource is done via negotiating different providers within a particular group. Hence, a task may have to be shared by several providers. A large-scale task can be shared as the following steps: ? Task decomposition: involves decomposing large task into subtasks. The task decomposition is typically done by the dispatcher.\par
? Task allocation: refers to assigning the subtasks into different providers.\par
? Task accomplishment: is the completion of the subtasks by the respectively dedicated providers, which could further include decomposition and subtasks assignment.\par
? Result synthesis: includes passing the results from different providers to the corresponding provider (usually who initiates the negotiation). The corresponding provider then composes the results and passes it to the user. 
\section[{V. Simulation Results and Evaluation}]{V. Simulation Results and Evaluation}\par
We conduct our simulations according to the resource configuration presented in Table  {\ref 1}. Column 1 of Table  {\ref 1} represents different parameters that a user and a provider use to set their agents. In our simulation environment, one can accommodate a large number of users as well as providers. To set this large number of users and providers with different requests and offers, we use ranges of values so that each participant can select a value from its respective range. All users' requests are set using the Column 2 ranges and all providers' offers are set using the Column 3 ranges automatically. Since, the provider agents do not change their resource prices over iterations; we use only a single range to define a resource unit price. The first range \hyperref[b0]{[1]}\hyperref[b1]{[2]}\hyperref[b2]{[3]}\hyperref[b3]{[4]}\hyperref[b4]{[5]} is used to refer to the price for 1 GB storage and the second range \hyperref[b9]{[10]}\hyperref[b10]{[11]}\hyperref[b11]{[12]}\hyperref[b12]{[13]}\hyperref[b13]{[14]}\hyperref[b14]{[15]}\hyperref[b15]{[16]} {\ref [17]} {\ref [18]} {\ref [19]} {\ref [20]} is used to refer to the price for the processor of 1 MIPS (Million Instructions Per Second) capacity. The deadline parameter might not be consistent in case of simulation and so we are not using time parameter to pricing resource cost (e.g. \$3/MIPS/hour). In addition, we assume concurrent arrival of different requests and offers. 
\section[{Table 1: Resource configuration a) Evaluation criteria}]{Table 1: Resource configuration a) Evaluation criteria}\par
In the Netlogo framework, three different results can be obtained based on the interaction of A u (useragent) and A p (provider-agent). The first result describes the job rejection rate for an A p . Job rejection occurs due to scenarios such as disagreement of resource prices or unavailability of resources. This rate is calculated using two parameters -the total number of rejected jobs (J rejected and the total number of requested jobs (J requested ). The job rejection rate is assumed to range from 0 to 1. The job rejection rate, R rate , is given by: We conduct our experiment with 5000 users and 250 providers and results are compared between group-based iCNP and traditional iCNP. The traditional approach is, using iCNP without applying our groupbased strategies. At first, we compare these two approaches in terms of job rejection rate. Job rejected rate is plotted in terms of a number of interactions between users and providers (requests).\par
Figure  {\ref 3} demonstrates the job rejection rate patterns between the two approaches. The horizontal axis describes the number of interactions between users and providers and the vertical axis shows the rate. The number of interactions is more than the total number of the user, since the protocol is iterative, which allows failed users re-interact to providers. 
\section[{Fig. 3: Job rejection rate comparison}]{Fig. 3: Job rejection rate comparison}\par
However, in terms of a number of interactions, our group-based approach outperforms than the traditional one, since a high number of interactions would require high communication process, which degrades system performance and keep failed users waiting for the following rounds. Our group-based optimization strategy helps to minimize the number of interactions by switching to appropriate groups based on users' optimizations. Even though the traditional approach uses optimization policy, because of not using characterizing jobs and grouping strategy, any provider can receive any job, which minimizes the probability to meet a job requirement by a single provider. The parallel trend of a particular rejection rate with the horizontal axis refers to accepting jobs and keeps the rejection rate constant. For the group-based approach, initially, the rejection rate fluctuates to 0.5. This happens due to rejecting a few jobs in the beginning. Then it abruptly goes down due to starting accepting jobs and almost keeps constant. At the end, some jobs are rejected. This might occur due to unavailable resources or the users reach their maximum budgets without getting their SLAs established. The second result demonstrates the total revenue earned by a provider or a group. It sums only the prices of the accepted jobs. Hence, the total revenue, Erev, is: Where l denotes the executed job number, j denotes a total number of executed jobs and M i defines agreed price (between a user and a provider) for the l th executed job. For revenue as well group-based approach performs better than the traditional (Figure  {\ref 4}). The variation in a number of interactions can be explained in a similar way as aforementioned. For revenue, it is an upward trend except while rejecting jobs. During rejection the trend keeps constant. For group-based approach, the trend is almost straight, which means jobs are accepted smoothly without many iterations. On the other hand, the trend for traditional approach starts off increasing (accepting jobs) smoothly, then after 5000 interactions (i.e. first round finished by dealing with 5000 users), it stops moving up (rejecting jobs) and gradually going up through a couple of iterations. In the end, for both cases system receives no revenue. The third output illustrates how the resources on provider side are utilized. In this paper, we consider the utilization of storage and CPU. The percentage of utilization, ?? ?? for a resource of type m by a provider A p can be calculated by using the following formula: \par
For resource utilization, we obtain similar patterns for both disk space and processors. Hence, we explain the utilization for disk space only (Figure  {\ref 5}). The simulation pattern illustrates the utilization pattern for 250 providers (along x-axis). Unlikely in the group-based approach, traditional approach does not share resources between providers. Hence, a chance to utilize more resources by a single provider decreases. For example, if a provider is unable to fulfill a user's requirements, the provider has to reject the job, since the provider does not support sharing resources with other providers. On the other hand, in our group-based approach, even if a provider is unable to fulfill a user's requirements, the provider still can communicate with Year 2 018 
\section[{( ) E}]{( ) E}\par
© 2018 Global Journals 1\par
Example 1: Resource Optimization. Figure  {\ref 6} shows the throughput of provider-provider negotiation within group-4 to optimize storage. Due to unavailable resources, user 247 is migrated from group-2 to group-4. 40\% of the user's storage demand is met by provider-6 and rest 60\% is shared by provider-8. Provider-4 is the group-4 correspondent here.\par
Example 2: Budget Optimization. Figure  {\ref 7} presents the budget optimization process within group-3. Though provider-4 and provider-6, both accept user 204's cfp, user 204 awarded provider-6, since provider-6's asking bid was less than that of provider-4. Please note that provider-6 is appeared in both groups, this is because of taking the two shots from different simulations. In practically, one provider cannot exist within different groups. The illustrations presented in this paper with the resource configuration in a way such that "supply is equal to demand". However, we conduct simulations with such other scenarios, which are "supply is greater than demand" and "supply is less than demand". Table  {\ref 2}: Scenario based comparison between group-based federated grid (GFD) and traditional grid (TG) For all three cases, we use the resource configuration according to Table  {\ref 1}. Table  {\ref 2} demonstrates that our group-based approach outperforms in most cases than the traditional approach. The group-based approach consumes less simulation time, produce less number of iterations, and even rejects fewer jobs in all three scenarios except when supply is greater than demand. Due to more supply compared to demand, the chance of accepting jobs by traditional provider increases. other providers within the group and share resources. Hence, the chance of accepting jobs and thus utilization resources increases. For group-based approach, most of the providers achieve maximum utilization (100\%) and a few of them are unable to utilize any resources. Typically, these providers are dedicated to optimize budget constraint by users and propose highest resource cost. Hence, it becomes hard to optimize budget by these providers and could not able to utilize any resources. However, the traditional grid providers could contribute their resources in a group-based federated grid, since the chance of utilizing maximum resources is higher in the group-based system than the traditional one. For the traditional approach, the trend is scatted across the figure, which implies the adoption of no optimization strategy. Year 2 018\par
( )E © 2018 Global Journals VI.\par
Conclusions and Future Work\par
The vision of grid computing is to collaborating computer resources that are distributed. However, due to the dynamic nature and heterogeneity of these resources, seamless collaboration is hindered. Agents are well known for collaborating distributed resources due to their autonomous and proactive nature in building decisions without human intervention. In this paper, we proposed an agent-based Iterated Contractnet-protocol to deal with users' QoS and providers satisfactions. We characterize users in terms of their preferences and switch them to the groups accordingly. A grouping strategy has been proposed for the federated grid, where grouping formed in terms of providers' availability and users' preferences. Our strategy enabled users to receive a stronger QoS without letting them waiting much. The less number of iterations and thus the less time consumption while negotiating between users and providers provided the justification of our approach. The adoption of such a group-based approach would produce less communication delay while dealing with thousands of users as well as providers. In addition, this would minimize execution uncertainty while ensuring better payoff and resource utilization by providers.\par
In future, we would like to conduct our experiments in real grid scenarios such as Globus, Nimrod in order to test the real-time adaptability and feasibility of our work. Future work would also extend the characteristic functions to distinguish between users in order to maximize the number of delivering required QoSs. We further would like to experience the agent behavior in terms of dealing with distributed environment and adapting accordingly.\begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-2.png}
\caption{\label{fig_0}PFig. 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-3.png}
\caption{\label{fig_1}Fig. 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-4.png}
\caption{\label{fig_2}( 1 )}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{453}\includegraphics[]{image-5.png}
\caption{\label{fig_3}Fig. 4 :Fig. 5 : 3 )}\end{figure}
  \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.0323559670781893\textwidth}P{0.11455761316872427\textwidth}P{0.7030864197530864\textwidth}}
\tabcellsep 1.1\tabcellsep PROCEDURE: ITERATED\textunderscore CONTRACT\textunderscore NET\textunderscore PROTOCOL\\
\tabcellsep 1.2\tabcellsep begin\\
\tabcellsep 1.3\tabcellsep set job-settled false\\
\tabcellsep 1.4\tabcellsep set continue-iteration true\\
\tabcellsep 1.5\tabcellsep set number-of-iterations 1\\
\tabcellsep 1.6\tabcellsep begin\\
\tabcellsep 1.7\tabcellsep SUB-PROCEDURE: RECEIVE\textunderscore cfpus\\
\tabcellsep 1.8\tabcellsep evaluate cfpus by At\\
\tabcellsep 1.9\tabcellsep call appropriate groups Gs\\
\tabcellsep 1.10\tabcellsep end\\
\tabcellsep 1.11\tabcellsep begin\\
Year 2 018\tabcellsep 1.12 1.13 1.14 1.15 1.16\tabcellsep SUB-PROCEDURE: INTERACT\textunderscore GROUP while (continue-iteration = true) [ foreach cfp-list begin SUB-PROCEDURE: EVALUATE\textunderscore  cfp\textunderscore BY\textunderscore G\\
\tabcellsep 1.17\tabcellsep if (job-settled = true)\\
\tabcellsep 1.18\tabcellsep {}[Remove the cfp from cfp-list]\\
\tabcellsep 1.19\tabcellsep end\\
\tabcellsep 1.20\tabcellsep else Don't remove the cfp from cfp-list\\
\tabcellsep 1.21\tabcellsep call the corresponding Au for revising cfp\\
\tabcellsep 1.22\tabcellsep end\\
\tabcellsep 1.23\tabcellsep end\\
\tabcellsep 1.24\tabcellsep increment of number-of-iterations by 1\\
\tabcellsep 1.25\tabcellsep begin\\
\tabcellsep 1.26\tabcellsep SUB-PROCEDURE: EVALUATE\textunderscore POTENTIAL\textunderscore GROUP\\
\tabcellsep 1.27\tabcellsep if (length of potential-group = 0 or length of cfp-list = 0)\\
\tabcellsep 1.28\tabcellsep {}[set continue-iteration false]\\
\tabcellsep 1.29\tabcellsep end\\
\tabcellsep 1.30\tabcellsep end\\
\tabcellsep 1.31\tabcellsep ]\\
)\tabcellsep 1.32\tabcellsep end\\
E\tabcellsep \multicolumn{2}{l}{1.33 end}\\
(\tabcellsep \tabcellsep \\
© 2018 Global Journals 1\tabcellsep \tabcellsep \end{longtable} \par
 
\caption{\label{tab_1}Algorithm 1: Dealing Users with Group-based Iterated Contract Net Protocol}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.1080684596577017\textwidth}P{0.2743276283618582\textwidth}P{0.04987775061124694\textwidth}P{0.014547677261613691\textwidth}P{0.10183374083129584\textwidth}P{0.09975550122249388\textwidth}P{0.11638141809290953\textwidth}P{0.06442542787286064\textwidth}P{0.020782396088019562\textwidth}}
\tabcellsep \multicolumn{3}{l}{User/provider-level parameter}\tabcellsep \multicolumn{2}{l}{User-level-range}\tabcellsep \multicolumn{2}{l}{Provider-level-range}\\
\tabcellsep \multicolumn{3}{l}{Storage/diskspace (GB)}\tabcellsep 200-600\tabcellsep \tabcellsep 6000-10000\\
\multicolumn{4}{l}{Number of CPUs (MIPS per CPU)}\tabcellsep 10-30\tabcellsep \tabcellsep 800-850\\
\tabcellsep \multicolumn{3}{l}{Minimum Budget/demand (\$)}\tabcellsep 500-1000\tabcellsep \multicolumn{3}{l}{1-5 (/GB), 10-20 (/MIPS)}\\
\tabcellsep \multicolumn{2}{l}{Maximum Budge(\$)}\tabcellsep \tabcellsep \multicolumn{2}{l}{4000-5000}\tabcellsep \multicolumn{2}{l}{Not Considered}\tabcellsep Year 2 018\\
? ???? ==\tabcellsep ? ???????? ? ?????????\tabcellsep \tabcellsep (2)\tabcellsep \tabcellsep \tabcellsep \\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep )\\
\tabcellsep \tabcellsep \multicolumn{3}{l}{Group-based approach}\tabcellsep \multicolumn{2}{l}{Traditional approach}\tabcellsep ( E\\
\tabcellsep 0.8\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \\
Rejection rate\tabcellsep 0.2 0.4 0.6\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \\
\tabcellsep 0\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \\
\tabcellsep 0\tabcellsep 2000\tabcellsep 4000\tabcellsep 6000\tabcellsep 8000\tabcellsep 10000\tabcellsep 12000\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep © 2018 Global Journals\end{longtable} \par
 
\caption{\label{tab_2}Number of interactions with providers}\end{figure}
 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Damaceanu ()]{b13}\label{b13} 	 		‘An agent-based computational study of wealth distribution in function of resource growth interval using NetLogo’.  		 			R.-C Damaceanu 		.  	 	 		\textit{Applied Mathematics, and Computation}  		2008. 201 p. .  	 
\bibitem[Izakian et al. ()]{b1}\label{b1} 	 		‘An auction method for resource allocation in computational grids’.  		 			H Izakian 		,  		 			A Abraham 		,  		 			B T Ladani 		.  	 	 		\textit{Future Generation Computer Systems}  		2009. 26 p. .  	 
\bibitem[Stefano and Santoro ()]{b4}\label{b4} 	 		‘An economic model for resource management in a Grid-based content distribution network’.  		 			A Di Stefano 		,  		 			C Santoro 		.  	 	 		\textit{Future Generation Computer Systems}  		2008. 24 p. .  	 
\bibitem[Wei et al. ()]{b9}\label{b9} 	 		‘An Improved Ant Algorithm for Grid Task Scheduling Strategy’.  		 			Laizhi Wei 		,  		 			Xiaobin Zhang 		,  		 			Yun Li 		,  		 			Yujie Li 		.  	 	 		\textit{International Conference on},  				2012. 24 p. .  	 
\bibitem[Ku-Mahamud and Nasir ()]{b8}\label{b8} 	 		‘Ant Colony Algorithm for Job Scheduling in Grid Computing’.  		 			K R Ku-Mahamud 		,  		 			H J A Nasir 		.  		 \xref{http://dx.doi.org/10.1109/AMS.2010.21}{10.1109/AMS.2010.21}.  	 	 		\textit{Fourth Asia International Conference on Mathematical/Analytical Modelling and Computer Simulation},  				 (Kota Kinabalu, Malaysia)  		2010. 2010. p. .  	 
\bibitem[Yadav et al. (2014)]{b10}\label{b10} 	 		‘Costbased Job grouping and Scheduling Algorithm for Grid Computing Environments’.  		 			Sonal Yadav 		,  		 			Amit Agarwal 		,  		 			Ravi Rastogi 		.  	 	 		\textit{International Journal of Computer Applications}  		April 2014. 91  (15)  p. .  	 
\bibitem[Michael et al. ()]{b14}\label{b14} 	 		‘Experiences creating three implementations of the repast agent modeling toolkit’.  		 			J N Michael 		,  		 			T C Nicholson 		,  		 			R V Jerry 		.  	 	 		\textit{ACM Trans. Model. Comput. Simul}  		2006. 16 p. .  	 
\bibitem[Foundation for Intelligent Physical Agents ()]{b15}\label{b15} 	 		 \url{http://www.fipa.org/specs/fipa00030/}  	 	 		\textit{Foundation for Intelligent Physical Agents},  				2000.  	 
\bibitem[Rosemarry et al. (2012)]{b11}\label{b11} 	 		‘Grouping Based Job Scheduling Algorithm Using Priority Queue and Hybrid Algorithm in Grid Computing’.  		 			Pinky Rosemarry 		,  		 			Ravinder Singh 		,  		 			Payal Singhal 		,  		 			Dilip Sisodia 		.  	 	 		\textit{International Journal of Grid Computing \& Applications (IJGCA)}  		December 2012. 3  (4) .  	 
\bibitem[Isaac et al. ()]{b3}\label{b3} 	 		‘Optimizing decentralized grid markets through group selection’.  		 			C Isaac 		,  		 			S Ramon 		,  		 			A Oscar 		,  		 			J Liviu 		,  		 			F R Omer 		.  	 	 		\textit{Int. J. Web Grid Serv}  		2009. 4 p. .  	 
\bibitem[Massimiliano and Stefano ()]{b0}\label{b0} 	 		‘Resource allocation in grid computing: an economic model’.  		 			C Massimiliano 		,  		 			G Stefano 		.  	 	 		\textit{J. WSEAS Trans. Comp}  		2008. 3 p. .  	 
\bibitem[Kunal and Arobinda ()]{b6}\label{b6} 	 		‘Resource Selection in Grids Using Contract Net’.  		 			G Kunal 		,  		 			G Arobinda 		.  	 	 		\textit{Proceedings of the 16th Euromicro Conference on Parallel, Distributed and Network-Based Processing},  				 (the 16th Euromicro Conference on Parallel, Distributed and Network-Based Processing)  		2008. 2008. IEEE Computer Society.  	 
\bibitem[Ni et al. ()]{b2}\label{b2} 	 		‘Services selection based on commodity-market in grid workflow’.  		 			W.-C Ni 		,  		 			L.-C Liu 		,  		 			C Wu 		.  	 	 		\textit{Journal of Computer Applications}  		2007. 27 p. .  	 
\bibitem[Sallez et al. ()]{b12}\label{b12} 	 		‘Simulating intelligent routing in flexible manufacturing systems using NetLogo’.  		 			Y Sallez 		,  		 			T Berger 		,  		 			C Tahon 		.  	 	 		\textit{IEEE International Conference on Industrial Technology},  				2004. p. .  	 
\bibitem[Rajiv et al. ()]{b7}\label{b7} 	 		‘Sla-based cooperative super scheduling algorithms for computational grids’.  		 			R Rajiv 		,  		 			H Aaron 		,  		 			B Rajkumar 		.  	 	 		\textit{J. ACM Transaction of Autonomous and Adaptive System}  		2008.  	 
\bibitem[Foster and Kesselman ()]{b5}\label{b5} 	 		\textit{The grid blueprint for a future computing infrastructure},  		 			A Foster 		,  		 			C Kesselman 		.  		1999. Morgan Kaufmann.  	 
\end{bibitemlist}
 			 		 	 
\end{document}
