Failure to understand a response during a protocol
Nie można odpowiedzieć na wiadomość not-understood za pomocą wiadomości not-understood.
Protokół FIPA-request
Protokół, ktory pozwala zażądać od innego agenta wykonanie pewnych akcji, a agentowi odbiorcy albo wyrazić zgodę (agree) albo odmówić (not-understood, refuse).
W przypadku agree agent odbiorca potwierdza dodatkowo losy wykonanej akcji jako:
failure lub inform. W przypadku wykonania akcji agent odbiorca w wiadomości typu inform powiadamia jedynie nadawcę o wykonaniu akcji (Done(action)) lub powiadamia również o jej rezultacie (iota x (result action) x)
.
FIPA-query Protocol
Od odbiorcy żąda się, aby wykonał kilka akcji typu informacyjnego. Jeśli jest to akcja typu query-if, agent odpowiada za pomocą aktu typu inform. Jeśli jest to akcja typu query-ref, wykonuje się akcje typu inform-ref.
Protokół FIPA-request-when
Wyraża on w prosty sposób wiele intencji zawartych w żądaniach wykonania akcji.
Agent nadawca żąda od drugiego agenta odbiorcy wykonania akcji w przyszłości, jeśli warunki przed staną się prawdziwe. Jesli agent – odbiorca zrozumie żądanie (brak not-understood) i nie odmówi (brak refuse), czeka on na spełnienie warunków w celu wykonania zleconego zadania (wybiera agree). Następnie (jeśli warunki zostały spełnione) odbiorca informuje o wykonaniu akcji (inform) lub o błędzie (failure), w przeciwnym wypadku, jeśli warunki nie zostały spełnione, odrzuca propozycję wykonania akcji (reject).
Protokół FIPA-contract-net
Jest to szeroko używany protokół Contract Net, zdefiniowany na podstawie [Smith &
Davis 80]. FIPA-Contract-Net jest niewielką modyfikacją oryginalnego protokołu przez dodanie aktów komunikacyjnych: rejection i confirmation. W protokole tym jeden agent pełni rolę menedżera. Menedżer rozsyła informację powiadamiającą o oczekiwaniu na propozycje wykonania pewnych zadań. Nadesłane propozycje wykonania zadań menedżer ocenia zgodnie z pewną funkcją, stąd przyjmuje część lub wszystkie nadesłane propozycje, jeśli wpłyną przed upływem zadanego czasu, a jeśli nie spełniają kryteriów – odrzuca je. Ta ocena propozycji nadesłanych jest najczęściej wyrażana za pomocą ceny, czasu itp. Menedżer może skasować działania agentów wykonawczych przed wykonaniem zadania.
FIPA-Iterated-Contract-Net Protocol
Protokół Iterated contract net jest rozszerzeniem podstawowego protokołu contract net. Różni się on od podstawowej wersji zastosowaniem pętli umożliwiającej wielokrotne uzgadnianie oferty. Menedżer wysyła wiadomość inicjującą typu cfp.
Kontrahenci odpowiadają za pomocą wiadomości typu propose. Menedżer może zaakceptować jedna lub wiele ofert, odrzucić inne lub może on iteracyjnie inicjować ponownie proces uzgadaniania ofert. Intencją menedżera jest otrzymanie najlepszej oferty od kontrahentów za pomocą modyfikacji oferty inicjującej i żądania nowych ofert. Proces kończy się, kiedy menedżer odrzuci wszystkie propozycje i nie złoży nowej oferty inicjującej, akceptując jedną lub więcej ofert lub odrzucając wszystkie oferty.
FIPA-Auction-English Protocol
W aukcji typu angielskiego aukcjoner poszukuje ceny rynkowej na towar, inicjując ją poniżej wartości rynkowej towaru. Następnie stopniowo ją podnosi. Za każdym razem cena jest ogłaszana i aukcjoner obserwuje, czy znajdzie się nabywca. Po każdej nowej propozycji ze strony kupujących aukcjoner czeka na nową wyższą ofertę i wybiera w danym momencie jedną najwyżsą ofertę ceny kupna towaru. Aukcja trwa do momentu, gdy są zakończy się zgłaszanie nowej oferty kupna towaru. Ostatnia oferta cenowa jest ostateczną ceną sprzedaży, jeśli nie jest mniejsza od pewnej ceny ustalonej przez aukcjonera. Jeśli jest ona mniejsza, towar nie zostanie sprzedany.
W diagramie protokołu oferta aukcjonera jest wyrażona za pomocą wiadomości cfp, rozesłanej do wszystkich uczestników aukcji. Da ułatwienia tylko jedno wystąpienie wiadomości jest przedstawiane. W fizycznej aukcji obecność uczestników aukcji w jednym pomieszczeniu umożliwia rozgłaszane jednej najwyższej oferty kupna do wszystkich uczestników aukcji – nie tylko do aukcjonera. To nie musi być prawda w przypadku systemu wieloagentowego, gdzie więcej niż jeden agent może oferować cenę w danym momencie. Nawet jeśli aukcja jest kontynuowana, dopóty, dopóki jest przynajmniej jeden pośrednik, agenty oczekują, czy ich oferta została zaakceptowana (reprezentowana za pomoca wiadomości propose). Stąd pojawiają się wiadomości typu accept-proposal i reject-proposal.
FIPA-Auction-Dutch Protocol
W aukcji typu holenderskiego, prowadzacy aukcję próbuje znaleźć cenę rynkową dla towaru podając cenę dużo wyższą niż spodziewana cena rynkowa. Następnie, stopniowo redukuje jej wysokość, aż kupujący zaakceptują jej wysokość. Jednak aukcjoner nie może zejść poniżej pewnej granicznej ceny – w momencie przekroczenia tej granicy, jeśli nie znajdzie sie kupujący, aukcjoner przerywa aukcję.
Nazwa "Dutch Auction" wywodzi sie z aukcji kwiatów w Holandii. W modelowaniu aktualnej aukcji kwiatów dochodzą dodatkowe problemy. Po pierwsze, wyroby mogą być sprzedawane w różnych jednostkach: sztukach, skrzynkach, natomiast kupujący chciałby kupić towar, lecz mniejszej ilości (zamiast proponowanych 5 skrzynek tylko trzy). Sprzedaż (o ile to możliwe, również w zmiennych jednostkach) jest kontynuowana, aż towary zostana sprzedane, albo zostanie osiągnięta cena graniczna.
Po drugie, mechanism targu kwiatów funkcjonuje przy założeniu, że nie ma zmowy po stronie kupujących, co osiąga się za pomocą jednej oferty cenowej na towar. Nie jest możliwe, aby istniał protokół akceptacji lub odrzucenia idei jednej oferty cenowej.
Z punktu widzenia agentowego nie jest możliwe, aby założyć lub oczekiwać, że takie warunki można zastosować. Jest całkiem możliwe, że może pojawić kilka ofert cenowych na ten sam towar. Protokół każe odzucić te dodatkowe oferty, chociaż można przyjąć również wariant wielu ofert dla innej dziedziny niż sprzedaż towarów (kwiatów).