SWI080 Zkouškové otázky

Zkouškové otázky k Middleware

Varování

Nejsou zde všechny otázky.

Introduction

Questions

1. Explain the term client-server architecture.
   • architektura, která popisuje aplikaci, jenž je rozdělená na dvě části: klientskou a serverovou
   • klient prezentuje data, server se stará o jejich uložení, výpočet nebo přípravu
   • Thick client – většina práce probíhá u klienta, snižuje se režie na přenos po síti, vytíženost serveru, komplikovanější aktualizace SW na všech klientech (např. distribuovaný filesystem)
   • Thin client – většina práce probíhá na serveru, umožňuje to velmi zjednodušit klienta a jeho zařízení, snadná aktualizace SW (např. klienti jako terminály)
      
2. Explain the term two-tier architecture.
   • client-server architektura
3. Explain the term three-tier architecture.
   • client-server architektura s přidanou vrstvou – middle tier, implementuje aplikační logiku nebo takové vlastnosti aplikace, které stojí na pomezí mezi vývojář aplikace a síťaři
   • prezentační vrstva, aplikační vrstva, databáze
4. Explain the term middleware.
   • vrstva, která z lokální aplikace vytváří distribuovanou
   • vrstva, která propojuje client-side a server-side
   • vrstva s vlastnostmi, které značně zjednodušují vývoj aplikační i serverové části

Communication

Questions - unicast

1. Define the properties of an ideally reliable communication mechanism in terms of messages sent and received by the participants. (hint: What exactly does it mean that communication is reliable? What is guaranteed when a participant sends a message? What is guaranteed when a participant receives a message?)
   • každá zpráva (data) odeslaná odesílatelem jsou přijata příjemcem právě jednou a nepoškozená (exactly once)
      
2. Describe the circumstances under which packet damage cannot be masked by the approaches used to provide reliable communication.
   • data duplication (=každá zpráva se posílá vícekrát) - nezjistí se chyba, pokud je poškozen bit ve zprávě a odpovídající bit v duplikované části
   • checksum, parita – nezjistí se chyba vzniklá poškozením dvou bitů ve zprávě
   • cross parity – nezjistí se chyba vzniklá poškozením tří bitů ve zprávě
   • CRC – vícebitové chyby vzdálené více než 16 bitů
      
3. Describe the circumstances under which packet loss and packet duplication cannot be masked by the approaches used to provide reliable communication.
   • amnesia failures - odesílatel nebo příjemce zapomenou sekvenční číslování paketů, nemohou se z toho vzpamatovat
      
4. The TCP flow control mechanism is based on the receiver informing the sender of the number of bytes that it can still accept. Explain why this approach is used instead of the receiver simply telling the sender whether it can accept any data or not.
   • z odpovědi ano/ne by odesílatel nepoznal, kolik toho ještě může poslat, a tak by mohl poslat více, než je příjemce schopen zpracovat, a režie na opakování komunikace by byla větší než komunikace o okně příjemce

Exercise 1 - unicast

Navrhněte přenosový protokol, který bude zaručovat spolehlivé doručování zpráv od jednoho odesílatele jednomu příjemci. Váš návrh by měl definovat tyto funkce:

void ReliableSend (tMsg *pMessage, tAddr *pTarget);
 // Odeslání zprávy, blokuje do přijetí zprávy

void ReliableReceive (tMsg &*pMessage, tAddr &*pSource);
 // Příjem zprávy, blokuje do přijetí zprávy, zaručuje
 // právě jeden příjem nepoškozené odeslané zprávy

Váš návrh by měl používat tyto funkce:

void UnreliableSend (tMsg *pMessage, tAddr *pTarget);
 // Odeslání zprávy, neblokuje, nemusí odeslat

void UnreliableReceive (tMsg &*pMessage, tAddr &*pSource, int iTimeout);
 // Příjem zprávy, blokuje do timeoutu, může přijmout
 // poškozenou zprávu nebo tutéž zprávu vícekrát

Dále předpokládejte existenci rozumných funkcí pro manipulaci se zprávami jako je jejich vytváření a rušení, nastavování a dotazování atributů přenášených spolu s obsahem zprávy a podobně.
Pozor: při odesílání - pokud nesouhlasí hash, je třeba poslat NAK, a počkat na opětovný příjem zprávy. Při odesílání ACK je třeba přidat do zprávy id.

reliable_send(message, target)
{
  id = unique++; //unique je globalni sekvence pro daneho targeta

  m = pack_message(message, id, hash(message))

  unreliable_send(m);
  while(1);
  {
    unreliable_recieve(message, target, timeout);
    if (message.type = ACK AND message.id = id) break;
    unreliable_send(m);
  }
}

reliable_receive(message, source)
{
  While (1)
  {
    Unreliable_recieve(inmessage, source, timeout)
    If hash(inmessage.zprava) == inmessage.hash
    {
      If inmessage.id < id_narade
      {
        Unreliable_send(ACK, source);
      }
      If  inmessage.id = id_narade
      {
        Unreliable_send(ACK, source);
        Message = inmessage;
        Id_Narade++;
        Return 0;
      }
   }
}

Questions - multicast

1. The sender initiated and receiver initiated error recovery schemes differ in which of the two communicating sides is responsible for keeping track of delivered packets. Explain how this difference impacts the management of memory used to store packets.
   • sender initiated – odesílatel si musí udržovat seznam všech příjemců a evidovat si jejich potvrzování, což může být ve velkých sítích velmi vysoké číslo, špatně se škáluje
   • reciever initiated – NAK při nepřijmutí paketu, musí ale vědět, že měl data přijímat. To lze v souvislém proudu paketů řešit timeouty, při nesouvislém proudu pomocí keep-alive paketů.
      
2. The use of positive acknowledgements in multicast can lead to network congestion problems due to excessive acknowledgement traffic, also termed as ACK implosion. Outline scenarios in which this problem occurs and approaches used to remedy the problem while preserving positive acknowledgements.
   • příliš mnoho uzlů potvrdí příjem paketu v jednom okamžiku a tím se zahltí síť poblíž odesílatele
   • řešení: stromová topologie - ACK posílají pouze potomci přímým předchůdcům poté, co dorazí ACK od všech potomků
      
3. The use of negative acknowledgements in multicast can lead to network congestion problems due to excessive acknowledgement traffic, also termed as NAK implosion. Outline scenarios in which this problem occurs and approaches used to remedy the problem while preserving negative acknowledgements.
   • když moc příjemců neobdrží v timeoutu paket, odesílají NAK – těch se hodně sejde u odesílatele a síť se zahltí
   • řešení: NAK posíláno jako multicast, čekat náhodnou dobu před odesláním NAK; pokud během této doby přijde NAK od jiného uzlu, nemusí se již NAK posílat
      
4. Define the source ordering guarantees in the context of multicast communication and explain in what situations and why this ordering is useful.
   • data od jednoho odesílatele budou přijata ve stejném pořadí, jako byla odeslána
   • kdy je to užitečné??
      
5. Define the causal ordering guarantees in the context of multicast communication and explain in what situations and why this ordering is useful.
   • data jsou obdržena podle kauzální závislosti: jestliže existuje proces, ve kterém událost e1 předchází e2, potom e2 kauzálně závisí na e1, příjem zprávy kauzálně závisí na odeslání zprávy, funguje tranzitivita
   • data o příčinách přijdou před daty o následcích
   • kdy je to užitečné??
      
6. Define the total ordering guarantees in the context of multicast communication and explain in what situations and why this ordering is useful.
   • totální kauzální doručování – data budou doručena všem příjemcům ve stejném pořadí
   • kdy je to užitečné??
      
7. In a form of algorithms used by the senders and the receivers, sketch the approach used to achieve source ordering in multicast communication.
   • odesílatel provádí sekvenční číslování paketů a příjemce po obdržení zprávu přijme pouze v tom případě, že již dříve přijal zprávu s předcházejícím ID od toho samého odesílatele
      
8. In a form of algorithms used by the senders and the receivers, sketch the approach used to achieve causal ordering in multicast communication. Use of a distributed algorithm is considered better than use of a centralized one.
   • Kauzální uspořádání zajistí vektorové hodiny, které nastavuje odesílatel. Příjemce po obdržení zprávu doručí pouze v tom případě, že již dříve přijal zprávu s předcházejícím ID ze stejné skupiny.
      
9. In a form of algorithms used by the senders and the receivers, sketch the approach used to achieve total ordering in multicast communication. Use of a distributed algorithm is considered better than use of a centralized one.
   • Sekvenční číslování zpráv zajištěné centrální autoritou, příjemce po obdržení zprávu přijme pouze v tom případě, že již dříve přijal zprávu s předcházejícícm ID ze stejné skupiny
   • Distribuovaný total-order protokol: skalární vektorové hodiny. Odesílatelé rozešlou zprávy, příjemce při příjmu vrací odesílateli potvrzení TSAi, odesílatel po přijmutí všech potvrzení odešle finalizační zprávu s TSF = max(TSAi), po příjmu finalizační zprávy doručí příjemce zprávy podle TSF
      
10. The Lamport Clock is a logical clock used in some distributed algorithms. Outline the algorithm used to calculate the Lamport Clock timestamp and explain what are the useful properties of the timestamp.
    • Každý proces má timestamp
      • timestamp se zvedne při každé důležité události
      • při odesílání zprávy se připojí timestamp
      • při příjmu zprávy se případně zvedne timestamp nad přijatý
    • Pokud událost A kauzálně předchází B, pak timestamp A je menší než B. Naopak neplatí
       
11. The Vector Clock is a logical clock used in some distributed algorithms. Outline the algorithm used to calculate the Vector Clock timestamp and explain what are the useful properties of the timestamp.
    • každý proces má timestampy všech
    • svůj timestamp zvedne při každé důležité události
    • při odesílání zprávy se připojí timestamp
    • při příjmu zprávy se případně zvednou všechny timestampy nad přijaté
    • Událost A kauzálně předchází B <=> timestamp A je menší než B.
    • Událost A nemá kauzální vztah k B <=> timestamp A není porovnatelný s B.
    • porovnává se po složkách; je větší, pokud všechny složky jsou větší nebo rovno a jedna větší
       
12. Present a suitable example of a multicast communication in which sender ordering is violated. Explain why the ordering is violated. Use a notation in which S(A,X->B,C) denotes node A sending message X to nodes B and C and R(A,X) denotes node A receiving message X.
    • S(A,X1->B,C), R(B,X1), S(A,X2->B,C), R(C,X2), R(B,X2), R(C,X1)
       
13. Present a suitable example of a multicast communication in which causal ordering is violated, but less strict ordering guarantees are preserved. Explain why the ordering is violated. Use a notation in which S(A,X->B,C) denotes node A sending message X to nodes B and C and R(A,X) denotes node A receiving message X.
    • S(A,X1->B,C), S(B,X3->A,C),
    • S(A,X2->B,C), S(B,X4->A,C)
    • R(C, X1)
    • R(C, X3)
    • R(C, X4)
    • R(C, X2)
       
14. Present a suitable example of a multicast communication in which total ordering is violated, but less strict ordering guarantees are preserved. Explain why the ordering is violated. Use a notation in which S(A,X->B,C) denotes node A sending message X to nodes B and C and R(A,X) denotes node A receiving message X.
    • S(A,X1->B,C,D), S(B,X3->A,C,D),
    • S(A,X2->B,C,D), S(B,X4->A,C,D)
    • R(C, X1), R(C, X2), R(C, X3), R(C, X4)
    • R(D, X1), R(D, X3), R(D, X2), R(D, X4)

Exercise 1 - multicast

Navrhněte přenosový protokol, který bude zaručovat spolehlivé doručování zpráv od jednoho odesílatele více příjemcům. Váš návrh by měl definovat tyto funkce:

void ReliableSend (tMsg *pMessage, tAddrList *pTargetList);
 // Odeslání zprávy, blokuje do pˇřijetí zprávy všemi příjemci

void ReliableReceive (tMsg &*pMessage, tAddr &*pSource);
 // Příjem zprávy, blokuje do přijetí zprávy, zaručuje
 // právě jeden příjem nepoškozené odeslané zprávy

Váš návrh by měl používat tyto funkce:

void UnreliableSend (tMsg *pMessage, tAddr *pTarget);
 // Odeslání zprávy, neblokuje, nemusí odeslat

void UnreliableReceive (tMsg &*pMessage, tAddr &*pSource, int iTimeout);
 // Příjem zprávy, blokuje do timeoutu, může přijmout
 // poškozenou zprávu nebo tutéž zprávu vícekrát

Dále předpokládejte existenci rozumných funkcí pro manipulaci se zprávami jako je jejich vytváření a rušení, nastavování a dotazování atributů přenášených spolu s obsahem zprávy a podobně a existenci rozumných funkcí pro manipulaci se seznamem adres jako je jeho procházení.

Zadání vyžaduje návrh protokolu pro spolehlivý multicast nad nespolehlivým unicastem, na rozdíl od obvyklejšího návrhu spolehlivého multicastu nad nespolehlivým multicastem. Vysvětlete, jaký má toto omezení vliv na vlastnosti vašeho návrhu.

// Odeslání zprávy, blokuje do přijetí zprávy všemi příjemci
void ReliableSend (tMsg *pMessage, tAddrList *pTargetList)
{
  bool Prijato[id .. targetlist.size];
  bool timeout[id .. targetlist.size];

  for target in targetlist
  {	
    id = unique++; //unique je globalni sekvence pro daneho targeta
    m = pack_message(message, id, hash(message))
    unreliable_send(m);

    while(1) 
    {
      unreliable_recieve(message, target, timeout);
      if message.type = ACK AND message.id = id 
      {
        break;
      }
      unreliable_send(m);
    }
  }
}

// Příjem zprávy, blokuje do přijetí zprávy, zaručuje
// právě jeden příjem nepoškozené odeslané zprávy
void ReliableReceive (tMsg &*pMessage, tAddr &*pSource);
{
  Unreliable_recieve(inmessage, source, timeout)

  If hash(inmessage.zprava) == inmessage.hash
  {
    If inmessage.id < id_narade
    {
      Unreliable_send(ACK, source);
    }
    If  inmessage.id = id_narade
    {
      Unreliable_send(ACK, source);
      Message = inmessage;
      Narade++;
      Return 0;
    }
  }
}

Questions - Addressing by Content

1. Explain how distributed hashing can be employed to implement a simple distributed file sharing service. Discuss the limitations of such an implementation in terms of the search query complexity.
   • soubory, adresáře = hodnoty, těm jsou přiřazeny klíče (keys)
   • uzly sítě = nodes, těm jsou přiřazeny identifikátory (IDs)
   • store(key, value) - najít příslušný uzel a uložit data
   • lookup(key) - najít příslušný uzel
   • join(id), leave(id)
   • uzel má na starost soubory, jejichž klíč je nejblíže ID uzlu
   • o úspěšnosti sítě rozhoduje: graf překrytí uzlů (outgoing arity of each node), jak přidávat nové uzly do grafu a jak je zase odebírat, jak je možné jej implementovat
   • u systému CHORD je doba na lookup omezena shora M, ideálně je O(log2N)

Questions - Messaging Interfaces

1. Design an interface of a messaging middleware that is suitable for a highly efficient transport of messages between processes of a tightly coupled homogeneous multiprocessor cluster, to be used for scientific calculations. Explain your design choices and advocate the suitability of your design.
   • Send(target, *message_ptr)
   • Receive(source, *message_ptr)
   • je možné použít předávání pomocí reference, jelikož pointry odesílatele budou dávat u příjemce smysl
   • send zprávu nahraje do sdílené paměti všemi procesy a pošle pointer do téhle paměti
   • není potřeba se zabývat reprezentací dat – v rámci homogenního clusteru bude stejná
   • velikost zprávy může být uložená na prvním bloku paměti kam ukazuje pointer
      
2. Design an interface of a messaging middleware that is suitable for an internet wide transport of messages between heterogeneous desktop computers, to be used for thick client information system running on multiple client platforms. Explain your design choices and advocate the suitability of your design.
   • Send(target, message, representation_description, size)
   • Receive(source, message, representation_description, size)
   • je potřeba popsat reprezentaci dat – u příjemce se může lišit
   • je třeba uvést velikost zprávy, aby nemusely být všechny stejně velké
   • předávání hodnotou

Questions - Remote Procedure Call

1. When invoking a procedure that passes an argument by value, RPC middleware has to handle situations where binary representation of the values differs between the client and the server. Outline and discuss the approaches used to do this.
   • společná reprezentace dat - mezitvar, například pomocí XDR – eXternal Data Representation, to je zbytečné, pokud byly obě architektury stejné, na druhou stranu zprávy jsou kratší
   • popis reprezentace může být uložen přímo ve zprávě, je to flexibilnější, ale zprávy jsou delší
   • zúčastněné strany budou znát navzájem své konvence, převod se uskuteční jen jednou pro každou zprávu a jen na jedné straně
   • může nastat ztráta přesnosti čísel, nemožnost přenosu některých speciálních znaků
      
2. When invoking a procedure that passes an argument by reference, RPC middleware has to handle situations where the reference has no meaning outside the address space of the client or the server. Outline and discuss the approaches used to do this.
   • obvykle se převádí na parametr určený hodnotou
   • strategie copy/restore - ta předpokládá, že objekt, na který ukazatel ukazuje, je nejprve zkopírován (resp. přenesen) i na server. Vzdálená procedura pak při svém volání dostane ukazatel na tento zkopírovaný exemplář programového objektu, který pak může v rámci své činnosti příslušným způsobem modifikovat. Jakmile provádění vzdálené procedury skončí, je dotyčný objekt zase zkopírován zpět na klienta.
   • problém – reference na funkce, reference mohou obsahovat další reference
      
3. Napište kód stubu na straně klienta a na straně serveru tak, aby zprostředkoval vzdálené volání funkce int read (int iFile, void *pBuffer, int iSize), která prečte data z otevřeného souboru. Váš návrh by měl používat níže uvedené funkce. Dále předpokládejte existenci rozumných funkcí pro manipulaci se zprávami jako je jejich vytváření a rušení, přístup k obsahu zprávy a podobně.

void ReliableSend (tMsg *pMessage, tAddr *pTarget);
 // Odeslání zprávy, blokuje do přijetí zprávy

void ReliableReceive (tMsg &*pMessage, tAddr &*pSource);
 // Příjem zprávy, blokuje do přijetí zprávy, zaručuje
 // právě jeden příjem nepoškozené odeslané zprávy

• -> http://nenya.ms.mff.cuni.cz/~ceres/wik/mwy/uploads/Main/Lubos-RPC.pdf

Systems

Questions - GM

1. To achieve maximum efficiency, the GM library is designed to minimize the need for copying data while communicating. Explain how the design minimizes data copying.
   • aplikace sama poskytne GM jeden buffer (lépe dva) pro každou prioritu a délku zprávy, kterou může přijmout – GM přímo tyto buffery plní a aplikace z nich čte, takže není potřeba nic kopírovat
   • vždy se plní jeden buffer, zatímco druhý se zpracovává
   • během komunikace se nemusí nic dynamicky alokovat

Questions - WS

1. Vysvětlete, jak standardy SOAP, WSDL a UDDI spolupracují v prostředí Web Services.
   • UDDI (Universal Description, Discovery, and Integration) - registruje a vyhledává webové služby, obsahuje informace o providerovi služby a její WSDL popis
   • WSDL (Web Service Description Language) - popis webové služby - datové typy, formát zpráv, kódování, protokol a síťová adresa služby
   • SOAP (Simple Object Access Protocol) - komunikační protokol, formát XML, snadný přenos pomocí HTTP

1. Describe the reasons for choosing XML as the transport encoding in web services.
   • Pros: it's everywhere, easily readable, admin friendly, standardized
   • Cons: efficiency, implementation

Questions - DCE

1. DCE relies on UUID (Universally Unique Identifier) as a unique identifier to distinguish interfaces. Explain how an UUID can be generated so that its uniqueness is guaranteed.
   • součet reálného času, ID uzlu (MAC adresa, IP adresa) a (pseudo)náhodného generátoru
   • číslo má 128 bitů – výsledek MD5 nebo SHA1
   • generátor může být nahrazen dostatečně "náhodnou" hodnotou na hostitelském počítači – stack pointer, použitá paměť, TLB miss, swap size, paging size, ...
      
2. Using an argument with the pipe annotation, DCE allows a stream between the client and the server to be created within the context of a remote call. The argument with the pipe annotation is mapped to a pair of push and pull functions. Explain how these functions are used.
   • funkce implementuje klient
   • pipe je složena z "chunks", na začátk je v pipe specifikován počet elementů v chunku, element jsou typovaná data
   • pipe může být input parameter (klient-server kanál), output parameter (server-klint kanál), nebo obojí
   • push – pushes next chunk of data from pipe to caller
   • pull – pulls next chunk of data from klient side into pipe
   • pipe není idempotentní – nemůže být obsahem jiné pipe

Questions - EJB

• Něco málo k Beanům na Wiki

1. Explain what a bean and a container is in EJB.
   • bean – server-side component zapouzdřující bussiness logiku aplikace
   • container – poskytuje pro beans standardní služby, např. lifecycle, transakce; umožňuje klientům přístup k beans
      
2. The EJB standard defines stateful session beans, stateless session beans, message driven beans and entities. Describe the basic properties and the intended application of these four types of beans.
   • session bean reprezentuje jednotlivého klienta uvnitř J2EE serveru
   • stateful session beans – stav objektu přetrvává mezi voláním jednotlivých metod, „conversation state“
   • stateless session beans – bezstavová entita, škálovatelná, může být použita více klienty
   • message drive beans – bean, ke které nepřistupuje klient přes interface, neuchovává si žádná data ani stav konverzace, všechny její instance jsou ekvivalentní, jedna instance může přijímat zprávy od více klientů
   • entities – pro databázové entity, „represents a business object in a persistent storage mechanism“, obvykle má každá entita příslušnou tabulku v databázi a každá instance entity odpovídá řádku v tabulce
      
3. Describe the lifecycle of a stateful session bean in EJB, that is, when instances of the bean are, or appear to be, created and destructed, from both the client and the server points of view.
   • client: Created when a reference is obtained, a business method to initialize the state, a method designated as a Remove method to discard the state
   • container: Activation and passivation, preserves conversational state as transitive closure of field values using serialization.
      
4. Describe the lifecycle of a stateless session bean in EJB, that is, when instances of the bean are, or appear to be, created and destructed, both from the client and the server points of view.
   • client: není třeba ukončovat stav
   • container: inicializace voláním setSessionContext, ejbCreate, nepřepíná se do pasivního módu, pro odstranění volá kontejner ejbRemove
      
5. Describe the lifecycle of a message driven bean in EJB, that is, when instances of the bean are, or appear to be, created and destructed, both from the client and the server points of view.
   • Lifecycle trivial since it is stateless.
   • client: metoda onMessage
   • container: vytváří pool of message-driven instances, pro každou instanci pak volá setMessageDrivenContext, ejbCreate na instanci, pro ukončení ejbRemove, pak je instance připravená na garbage collection, instance není nikdy ve stavu passive
      
6. Describe the lifecycle of an entity bean in EJB, that is, when instances of the bean are, or appear to be, created and destructed, both from the client and the server points of view.
   • client: metoda onMessage
   • podletohoto: spíš client: create->work->remove
   • container: vytváří instanci, předání kontextu do instance – setEntityContext, poté je instance v poolu, tam jsou všechny instance identické, nejsou spojeny s žádným objektem. Ven z poolu po volání create od klienta, kontejner pak volá ejbCreate a ejbPostCreate. Druhou možností je aktivace instance přes ejbActivate. Zpět do poolu při pasivaci instance – ejbPassivate, nebo po volání remove od klienta, pak ejbRemove. Pro odstranění instance z poolu je unsetEntityContext.
      
7. Explain what the business, remote and home interfaces of a bean are in EJB.
   • remote interface defines the business methods that are specific to the bean
   • home interface defines the bean's life cycle methods--create and remove. For entity beans, the home interface also defines finder methods and home methods. Finder methods are used to locate entity beans

Questions - JMS

1. Explain how the point-to-point message delivery model of JMS works.
   • existuje fronta, do které odesílatelé zprávy ukládají a příjemci je z ní vybírají
   • pokud neexistuje příjemce, zprávy se ve frontě ukládají
      
2. Explain how the publish-subscribe message delivery model of JMS works.
   • existuje kanál, který distribuuje zprávy připojeným příjemcům
   • pokud příjemce neexistuje, zprávy se zahazují
   • výjimkou je pojmenovaná durable subscription, která zaručuje, že se pro příjemce budou zprávy ukládat

Questions - MPI

1. Explain why all communication functions in MPI that deal with messages require a description of the message data type.
   • kvůli heterogennímu prostředí, ve kterém je možné MPI použít
   • zaručuje přenositelnost zpráv
      
2. Pick three of the functions provided by MPI for collective communication, listed below, and explain what they do:
   • int MPI_Barrier (MPI_Comm comm);
     • blokuje, dokud se všechy procesy nedostanou do této rutiny (rendez-vous)
   • int MPI_Bcast (void *buffer, ..., int root, MPI_Comm comm);
     • zasílá zprávu od jednoho procesu s označením „root“ všem ostatním procesům ve skupině, včetně sebe sama
   • int MPI_Gather (void *sendbuf, void *recvbuf, ..., int root, MPI_Comm comm);
     • sbírá (spojuje) dohromady data od více procesů
   • int MPI_Scatter (void *sendbuf, void *recvbuf, ..., int root, MPI_Comm comm);
     • odesílatel ABC, příjemci A, B, C
   • int MPI_Alltoall (void *sendbuf, void *recvbuf, ..., int root, MPI_Comm comm);
     • odesílatelé ABC, DEF, GHI, příjemci ADG ...
   • int MPI_Reduce (void *sendbuf, void *recvbuf, ..., MPI_Op op, int root, MPI_Comm comm);
     • odesílatelé A, B, C, příjemce A+B+C
   • int MPI_Scan (void *sendbuf, void *recvbuf, ..., MPI_Op op, int root, MPI_Comm comm);
     • odesílatelé A, B, C, příjemci A, A+B, A+B+C

Questions - Java RMI

1. The RMI technology uses standard Java interface definitions to describe the remotely accessible interfaces. Explain the limitations imposed on the interfaces by the RMI technology.

• Všechny vzdáleně přístupné objekty musí implmentovat java.rmi.Remote
• Každá vzdáleně přístupná metoda musí vyhazovat výjimku java.rmi.RemoteException
• Objekty, které se přenášejí po síti, musí být serializovatelné

Questions - DCOM

1. Microsoft DCOM rozlišuje in process a out of process servery podle toho, zda běží v procesu klienta nebo ve vlastním procesu. Vysvětlete, proč Microsoft DCOM tyto druhy procesů nabízí.
   • komponenta jako DLL nemůže běžet sama o sobě, běží v procesu klienta = in-process, registrace probíhá v registrech počítače pod classID dané komponenty, registruje se zejména threading model. + Rychlejší vykonávání metod serveru. - Stabilita: pokud server spadne, klient pravděpodobně také.
   • komponenta jako EXE může běžet sama = out process, místo registrace se volá CoInitializeEx s flagem threading modelu jako parametr. - Pomalejší volání metod serveru. + Stabilita: když spadne server, klient nespadne, protože server běží ve vlastním procesu.
      
2. Microsoft DCOM uses a combination of keepalive pinging and reference counting to garbage collect unused objects. Evaluate this approach from the scalability point of view.
   • reference counting je dobře škálovatelné, dobrý a rychlý přístup k určení živých objektů, ale neřeší cyclic garbage
   • počítání referencí nemusí vždy také přesně sedět – klient např. nevolá release
   • proto se pingá jenou za dvě minuty server, po třech chybějících ping je klient prohlášen za mrtvého a server tento objekt uvolní
   • pokud by se jen pingalo, vedlo by to k plýtvání pamětí
      
3. The IUnknown interface in Microsoft DCOM has the following methods. Explain the semantics of the methods.

interface IUnknown
{
  HRESULT QueryInterface (REFIID iid, void **ppvObject);
  ULONG AddRef (void);
  ULONG Release (void);
};

• QueryInterface - metoda slouží k dotazu na existující rozhraní, které je identifikováno prvním parametrem, v němž je uložen GUID požadovaného rozhraní. Pokud objekt rozhraní implementuje, je na něj vrácen ukazatel ve druhém parametru. není-li implementováno, nabývá návratová hodnota funkce hodnotu E_NOINTERFACE a druhý parametr má neplatnou hodnotu.
• AddRef - Metoda inkrementuje počítadlo referencí, tedy počet odkazů ze všech připojených klientů. Metoda vrací aktuální počet referencí.
• Release - Metoda dekrementuje počítadlo referencí. Pokud počítadlo klesne touto operací na hodnotu nula, objekt se může sám odstranit z paměti. Návratová hodnota udává stav počítadla po dekrementaci.

Questions Chord

1. The Chord middleware uses routing along a logical ring to deliver a message to a node with the address that is nearest to the message key. Describe the routing tables kept by the individual nodes and show the complexity of sending a message on a brief description of the routing algorithm.

Slajdy o DHT z PDSka

Questions - CORBA

1. The CORBA middleware relies on a specialized interface definition language to describe interfaces of remotely accessible objects. Explain why this choice was made rather than relying on the interface definitions in an implementation language.
   • při návrhu rozhraní v IDL máme volnou ruku ve výběru implementačního jazyka, musí pro něj být pouze mapování do IDL
      
2. Even though CORBA IDL interfaces are mapped into classes both in C++ and in Java, the CORBA IDL interface attributes are not mapped into class attributes in C++ nor in Java. Explain why and outline how the attributes are mapped.
   • atributy jsou mapovány na pár funkcí, které umožňují čtení a psaní atributu
   • to nám umožní mít readonly atributy, které jdou pouze číst
      
3. When mapping the CORBA IDL integer types into C++, the C++ integer types cannot be used directly because C++ does not define the precision of the integer types in as much detail as CORBA IDL. Explain how this problem is solved.
   • pomocí typedefu jsou namapovány na C++ integerový typ příslušného rozsahu (např. na 32 bit. stroji je CORBA::Long int)
   • specifikace C++ neurčuje velikost integeru
      
4. When mapping the CORBA IDL integer types into Java, not all the integer types can be mapped directly because Java does not provide all the precisions of the integer types available in CORBA IDL. Explain how this problem is solved.
   • je prohlášen "type mismatch" a vyhozena výjimka CORBA::DATA_CONVERSION
      
5. The CORBA IDL sequence type, which describes a variable length vector, has no direct counterpart in the basic C++ types. Explain how and why the type is mapped into C++.
   • mapování na třídu, která se chová jako pole s udanou délkou a maximální délkou
   • overloaded indexing operator
   • pro "bounded sequence" je maximální délka pole implicitně nastavená v typu a programátor ji nemůže ovlivnit
   • pro "unbounded sequence" je maximální délku možné změnit explicitním voláním metody length()
   • při změně velikosti je možná relokace celého pole, která spočívá ve vytvoření nové sekvence, překopírování starých dat a prohlášení staré za neplatnou
      
6. The CORBA IDL union type, which describes a container that can hold any single item of a choice of items and preserves information on which item is held at a given time, has no direct counterpart in the basic C++ nor Java types. Choose either C++ or Java and explain how and why CORBA IDL union is mapped into that language.
   • mapují se na C++ třídy s funkcemi, které zpřístupňují union members (accessor functions), které mění union members (modifier functions)
   • používá se i diskriminator – funkce jenž určuje, která z položek unionu je ta aktivní
      
7. Nakreslete strukturu CORBA aplikace. Vyznačte, kde jsou umístěné nebo se používají IIOP, POA, proxy, servant, skeleton a stub a vysvětlete funkci těchto prvků.
   • IIOP (Internet Inter-ORB protocol) slouží ke komunikaci s objekty spuštěnými vzdáleně, je umístěn v ORB CORE, ta je obvykle přilinkována jako run-time library k serveru i klientu
   • POA – asociuje server s objekty, demultiplexuje příchozí požadavky na server a spolupracuje s IDL skeletonem na zavolání provedení správné operace volané od klienta na server
   • proxy - ekvivalent stubu, ale u DCOM
   • servant – server object implementation, instance objektu na serveru
   • stub – provádí marshallování na straně klienta
   • skeleton – prování unmarshalling na straně serveru
      
8. Při podpoře paralelního zpracování více požadavků na serveru se může použít model thread pool, ve kterém má server množinu vláken připravených k obsluze požadavků. Vysvětlete přednosti tohoto modelu a doplňte zde uvedený popis modelu o podrobnosti, o které se tyto přednosti opírají.
   • množiny vláken mohou být připravené podle priority (thready seskupeny dle priority do tzv. lanes)
   • množina vláken si bere požadavky z fonty a obsluhuje je. Pokud nejsou požadavky, uspí se nebo skončí
   • vhodné na real-time aplikace – je ušetřen overhead na vytváření a rušení vláken
      
9. Portable Object Adapter ve standardu CORBA dovoluje definovat default servant, kterému jsou doručeny všechny požadavky, pro které nebyl nalezen jiný servant. Vysvětlete, v jakých situacích je vhodné default servant použít.
   • množství objektů se stejným rozhraním sdílí jen jeden servant, jednotlivé objekty rozlišeny podle Object Id
      
10. Portable Object Adapter ve standardu CORBA dovoluje definovat servant activator, který je požádán o vytvoření servantu v situaci, kdy pro příchozí požadavek nebyl žádný servant nalezen. Vysvětlete, v jakých situacích je vhodné servant activator použít.
    • servant vytvořen až v okamžiku, kdy na něj přijde první požadavek
    • použití v případě, kdy inicializace servantu zabere hodně času (a během bootování by se mezitím nemohly zpracovávat žádné požadavky)
    • použití v případě, že server implementuje mnoho objektů, ale jen velmi málo se jich použije (zbytečně by všechny byly v paměti)
       
11. Portable Object Adapter ve standardu CORBA dovoluje nastavit pomocí servant retention policy zda se mají v tabulce active object map evidovat všechny aktivní servanty. Vysvětlete, v jakých situacích je vhodné upustit od evidence aktivních servantů v active object map.
    • RETAIN: The POA retains active servants in its active object map
    • NON_RETAIN: The POA has no active object map. For each request, the POA relies on the servant manager or default servant to map between an object and its servant; jako servant manager se zde používá servant locator
    • servant locator - aktivuje objekt při požadavku, deaktivuje objekt po dokončení; vhodné pro server s množstvím objektů, které ale není potřeba mít aktivní stále
       
12. Protokol GIOP ve standardu CORBA umožňuje pomocí zprávy LOCATION FORWARD informovat klienta o tom, že server se nachází jinde než se klient domníval. Vysvětlete, jak je tento mechanismus možné použít k implementaci persistentních objektů, jejichž reference zůstávají v platnosti i při ukončení serveru.
    • POA mediator handles requests in the case of server shutdown – sends location forvard message o the klient with the address of a new server to send requests to, the klient then sends all requests to the new server
       
13. Standard CORBA definuje službu Naming sloužící k registraci a vyhledávání serverů. Základní operace této služby jsou bind a resolve. Popište sémantiku těchto operací.
    void bind (in Name n, in Object obj) raises (AlreadyBound ...);
Object resolve (in Name n) raises (NotFound ...);
    • Bind – associate name with an object
    • Resole – finds object based on a name
       
14. Standard CORBA definuje službu Trading sloužící k registraci a vyhledávání serverů. Základní operace této služby jsou export a query. Popište sémantiku těchto operací.
    OfferId export (
  in Object reference,
  in
  ServiceTypeName type,
  in PropertySeq properties);
void query (
  in ServiceTypeName type,
  in Constraint constr,
  in Preference pref,
  ...
  out OfferSeq offers,
  out OfferIterator offer_itr,
  ...);
    • Export - zaregistruje službu u tradera, služba je identifkováan svým typem a vlastnostmi
    • Vyhledávání služeb u tradera
       
15. Standard CORBA nabízí možnost neblokujícího volání pomocí callbacku. Následující fragment CORBA IDL uvádí příklad blokující operace a k ní vygenerované rozhraní pro neblokující volání pomocí callbacku:
    // Příklad blokující operace
void example_operation (in string anInArgument, out double anOutArgument);

// Rozhraní pro neblokující volání
void sendc_example_operation (
  in AMI_ExampleHandler ami_handler,
  in string anInArgument);

interface AMI_ExampleHandler
{
  void example_operation (in double anOutArgument);
}
    
    Vysvětlete na tomto příkladu fungování neblokujícího volání pomocí callbacku.
    • klient je zodpovědný za poskytnutí objektu, který implementuje callback. Nejdříve se zavolá sendc_, ta předá odkaz na objekt a parametry a okamžitě se vrátí. Odpovědi už zpracovává AMI_example_handle
       
16. Standard CORBA nabízí možnost neblokujícího volání pomocí pollingu. Následující fragment CORBA IDL uvádí příklad blokující operace a k ní vygenerované rozhraní pro neblokující volání pomocí pollingu:
    
    // Příklad blokující operace
void example_operation (in string anInArgument, out double anOutArgument);

// Rozhraní pro neblokující volání
AMI_ExamplePoller sendp_example_operation (in string anInArgument);
valuetype AMI_StockManagerPoller
{
  void example_operation (in unsigned long timeout, out double anOutArgument);
}
    
    Vysvětlete na tomto příkladu fungování neblokujícího volání pomocí pollingu.
    • Sendp_ returns pointer to an AMI… It can be given a timeout, how long will klient wait Klient then subsequently query AMI… object to get the value

Questions - ProActive

1. The ProActive middleware uses futures to pass results of method invocations on active objects. Explain why.

Futures jsou použity pro repreznetaci výsledků asynchronních volání. Jinými slovy, mám výsledek funkce, který mohu libovolně ukládat, hrát si s ním, až na jednu drobnost: neznám ho. V okamžiku, kdy se dotážu na jeho hodnotu a vlastní funkce nedoběhla, tak se uspím, dokud není dostupný. Naopak, pokud v okamžiku dotázání, již existuje a je dostupný, tak si ho přečtu bez jakéhokoli čekání.

Questions - JavaSpaces

1. The basic operations of JavaSpace are write, read and take. Describe what these operations do.

interface JavaSpace
{
  Lease write (Entry e, Transaction tx, long lease);
  Entry read (Entry template, Transaction tx, long timeout);
  Entry take (Entry template, Transaction tx, long timeout);
  ...
}

• write - places a new Entry in the space.
• read - returns a copy of an Entry matching a particular template. Blocking, until one exists
• take - removes an Entry matching a particular template from the space and returns it to the caller. Blocks until one exists