==29760== 176 bytes in 4 blocks are definitely lost in loss record 9 of 15
==29760==    at 0x1B8FF896: malloc (vg_replace_malloc.c:149)
==29760==    by 0x8099DCF: transportAddressBlockDuplicate (transportaddressblock.c:227)
==29760==    by 0x809279C: scanServerInformationParameter (rserpoolmessageparser.c:1188)
==29760==    by 0x80934D9: scanListResponseMessage (rserpoolmessageparser.c:1528)
==29760==    by 0x8095B05: scanMessage (rserpoolmessageparser.c:2009)
==29760==    by 0x8096292: rserpoolPacket2Message (rserpoolmessageparser.c:2093)
==29760==    by 0x8071E5C: registrarSocketCallback (registrar.c:2820)
==29760==    by 0x8076ACF: dispatcherHandlePollResult (dispatcher.c:256)
==29760==    by 0x8074F0F: main (registrar.c:3556)
==29760==

------

Fehler:
- Starten: r1, r2, r3, p1
  p1 <-> r3
- Stoppen: r3
 Takeover r1/r2

 PE nimmt r1 oder r2 als PR-H
   -> handleRegistrationRequest ...
   -> Update im HS, aber Ownership-Checksum stimmt nicht mehr. => Assertion.

------

MacOS-Tests:
194.95.73.130
sudo kextload /System/Library/Extensions/SCTP.kext
sudo kextunload /System/Library/Extensions/SCTP.kext

-----

Testsoftware:
- Runs
- RunDuration

Synchronisation:
- Start-TS

getTimeStamp [offset]

--------

result = rsp_recvmsg()

result == 0: Session-Ende, kein FO mglich
result == -1, errno = EAGAIN (o..) -> FO mglich/kein Fehler, etc.
result >0: Data/Notif./Cookie


--------

Msg-Queue:
- Verhalten bei PR-Ausfall
- Statische PRs

- Load-Update in TCP/UDPLikeServer

--------


RSerPool-API:


Rckgabewerte fr rsp_write() / rsp_read():
  Notifications!!!!!

  RSPERR_FAILOVER_NECESSARY
    Nchster Aufruf wird Failover durchfhren
    Prfung, ob Cookie vorhanden: rsp_has_cookie(...)
  RSPERR_IO_TIMEOUT:
    Timeout ist aufgetreten, ggf. manueller Failover notwendig


 Rckgabe bei Failover:
   mit Cookie:
     Fehler RSPERR_AUTO_FAILOVER
   ohne Cookie:
     Fehler RSPERR_MANUAL_FAILOVER


NOSR
NOPKG
MSG_NOSIGNAL

------

PingPong Protocol:

Ping {
   MessageNo;
   Data[];
}

Pong {
   MessageNo;
   ReplyNo
   Data[];
}


------

Last fr ThreadedServer:
  Je Thread: weight, load e(0%,100%)
     => Gesamt-Last: gewichtete Load-Summe / Gewicht-Summe

   Threaded-Server (PE-sd, Session-ID)
     => setLoad() -> Berechnung ber List -> Update???
   oder ext. Fkt.  updateLoad()
      static FractalGenerator::updateLoad()

------

Notifications treten auf bei:
 read oder write
 -> nicht innerhalb Wartefunktion mit rsp_select()!


=================

TCP-Like:
 Server:
   PE -> ein Accept-Socket
   jede Session: eigenes RSerPool-Socket
 Client:
   Session -> eigenes Socket

UDP-Like:
 Server:
   PE -> ein UDP-like Socket
   write() -> Mit Session-ID bzw. PH -> ok.
   read()  -> Aggregat ber mehrere Sessions
      -> Session-ID wird mit gelesen.

 Client:
   write() -> Mit Session-ID bzw. PH -> ok.
   read()  -> Aggregat ber mehrere Sessions
      -> Session-ID wird mit gelesen.
      Ist das sinnvoll???

-----

Failover mit UDP-like Socket:
  =====
  RSerPoolSocket: Kommunikationsbeziehung
   PU: eine einzige Session
   PE: viele - eingehende - Sessions
  =====
  - Je RSerPool-Socket:
       Remote-PH
    Session besitzt keinen PH (das hat nur das Socket)!!!!
  PU: Es gibt nur *eine* Session!
      CommLost
      -> Session->AssocID = 0; merken, da im Failover-Zustand
      -> connect() ...
      -> CommUp
      -> Failover-Zustand -> Session->AssocID = newAssocID
      -> Failover-Prozedur.
      OK.
  PE: Es gibt viele Sessions (eingehende)
     CommLost
     -> Session entfernen
     CommUp
     -> Session hinzufgen
     -> Cookie annehmen
     OK.

     symmetrischer Fall:
     -------------------
     PE.Session macht Peel-Off fr neue Sessions
     Bei Ausfall mu dann Socket durch UDP-like ersetzt werden.


=================


oberhalb von rsp_read() / rsp_write(), z.B. l5_read() / l5_write() ...
- z.B. PPID = 55555555
- Multi-Streaming???????

L5DATA:
SeqNumber
AckNumber
Data
 ...

L5ACK:
AckNumber
Cookie (opt.)       !!!!!!!!!!!!!!!
 ...


l5d=l5_init(session, istreams, ostreams)
l5msg = l5_read(...) {
   l5_ack(l5ms, cookie)
}
l5_cleanup(l5d)


=================

- Registrar-Table:
  Timeouts korrigieren! OK
- Registrar:
  Filterung von Registrar-Transport
  => ASAPTransport
  => PeerPresence
  => Announce
   UDP: nur IP-Header-Sourceadresse
   SCTP: aus Assoc.

- Socket-API:
 * sctp_peeloff(sd, assocID) ohne Addrs.
 * MSG_ -> SCTP_
