BEEP The Blocks Extensible Exchange Protocol Core KM-/VS-Seminar Wintersemester 2002/2003 Betreuer: Frank Strauß

Übersicht Einleitung Konzeption von BEEP Core Nachrichtaustausch Frame der Nachrichten Sitzungsverwaltung Abbildung auf TCP Implementierung der Konzeption mit Java BEEP Client Server Zusammenfassung

1. Einleitung BEEP – Ein standardisierter Rahmenwerk für Internet- Protokoll RFC 3080 und RFC 3081 - Marshall Rose Zielsetzung des BEEPs Verbindungsorientierung, Nachrichtenorientierung, Asynchronisation

2. Konzept von BEEP Core BEEP ist ein Anwendungsprotokoll nach dem Peer-to-Peer- Prinzip. Funktionalitäten von BEEP: Trennen einer Nachricht von der Nächsten (Frame), Kodierung der Nachrichten, Unterstützung mehrfacher logischer Kommunikationskanäle, Berichten über Störungen, Aushandlung von Verschlüsselungsparametern, Aushandlung von Authentisierungsparametern.

2.1 Nachrichtaustausch Rolle Austauscharten Listening-Rolle – auf eine eingehende Verbindung wartet. Initiating-Rolle – eine Verbindung zum Listener erstellen will. Client und Server. Austauscharten message/reply message/error message/answer

2.2 Frame der Nachrichten Die BEEP-Nachrichten sind in der Regel durch MIME ‎[8] strukturiert. Text oder binärer Code. Beschreibung der Inhalttypen durch MIME-Kopf - „entity- headers“. Defaultwerte: „Content-Type“ - „application/octet-stream“, „Content-Transfer-Encoding“ - „binary“. Beschreibung der Nachrichten durch XML.

2.2 Frame der Nachrichten Syntax eines BEEP-Frames message frame frame header payload trailer header SP SP type channel SP SP megno more SP CR LF seqno size payload OCTET frame CR LF END

2.2 Frame der Nachrichten Kopf eines Frames channel identifiziert, auf welchem Kanal die BEEP-Peers miteinander kommunizieren sollen. msgno identifiziert die Nummern der Nachrichten. more ist ein Fortsetzungsindikator, der entweder mit „*“ oder mit „.“ gekennzeichnet wird. seqno identifiziert die Sequenznummer des ersten Oktetts in der Nutzlast. size kennzeichnet die Anzahl der Oktetts in der Nutzlast eines Frames.

2.2 Frame der Nachrichten Nutzlast Abschluss Ein Beispiel Besteht aus null oder mehren Oktetts, Zugeordnet durch Sequenznummer. Abschluss besteht aus der Zeichenkette END <CR> <LF> Ein Beispiel C: MSG 0 1 . 52 120 C: Content-Type: application/beep+xml C: <start number=’1’> C: <profile uri=’http://iana.org/beep/SASL/OTP’ /> C: </start> C: END

2.3 Sitzungsverwaltung Verteilung der Sitzung in verschiedenen Kanäle Kanal 0 - Verwaltungskanal Regelung durch Profile session . channel 0 (management) channel 1 (profile A) channel n (profile P, Q)

2.3 Sitzungsverwaltung Nachrichtenelement Nachrichten wird präsentiert durch Nachrichtenelement (XML-Element). Fünf Grundtypen von Nachrichtenelement für Sitzungsverwaltung, Beziehungen zwischen Rolle, Nachrichtenarten und Nachrichtenelement: Rolle MEG RPY ERR I und L greeting error I oder L start profile close ok

2.3 Sitzungsverwaltung Greeting-Nachrichten Start-Nachrichten L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: <greeting> L: <profile uri=’http://iana.org/beep/TLS’ /> L: </greeting> L: END I: RPY 0 0 . 0 110 I: Content-Type: application/beep+xml I: <greeting /> I: END Start-Nachrichten C: RPY 0 1 . 30 120 C: Content-Type: application/beep+xml C: C: <start number=’1’> C: <profile uri=’http://iana.org/beep/SASL/OTP’ /> C: <profile uri=’http://ibr.cs.tu-bs.de/fangming/contact’ /> C: </start> C: END

2.3 Sitzungsverwaltung Error-Nachrichten C: RPY 0 2 . 390 80 C: Content-Type: application/beep+xml C: <close number=’1’ code=’200’ /> C: END S: RPY 0 2 . 211 27 S: Content-Type: application/beep+xml S: <error code=’550’>still working</error> S: END Close-Nachrichten und OK-Nachrichten C: RPY 0 2 . 390 80 C: Content-Type: application/beep+xml C: C: <close number=’1’ code=’200’ /> C: END S: RPY 0 2 . 210 257 S: Content-Type: application/beep+xml S: S: <ok /> S: END

2.3 Sitzungsverwaltung Profile Vordefinierte Profile für: Ein Profile stellt dar, welche Nachrichten über den Kanal übertragen werden sollen/können. Ein Profile ist durch einen URI identifiziert und regelt die Syntax und Semantik zugelassener Nachrichten. Vordefinierte Profile für: Kanalmanagement, TLS – „Transport Layer Security“ – und Authentisierung.

2.4 Abbildung auf TCP Sitzungsverwaltung TCP A TCP B BEEP Peer A CLOSED OPEN-Active OPEN-Passive SYN, … SYN+ACK, … OPEN-Success ESTABLISHED ACK, … . …, <close number=’1’> BEEP Peer A BEEP Peer B Initiator Listener RECEIVE (<close>) SEND (<ok>) SEND (<close>) RECEIVE (<ok>) CLOSE …, <ok> FIN, … CLOSING TERMINATE

2.4 Abbildung auf TCP Nachrichtenaustausch TCP A TCP B BEEP Peer A ESTABLISHED SEND (<profile>) SEND (<start>) RECEIVE (<profile>) …, <profile url=’…’> . BEEP Peer A BEEP Peer B Client Server …, <start number=’1’> RECEIVE (<start>) initial channel 1 successful SEND (<error>) RECEIVE (<error>) …, <error code=’550’> …, <start number=’2’> initial channel 2 unsuccessful SEND (<greeting>) RECEIVE (<greeting>) …, <greeting> SEND (<query>) …, <query uid=’fm007’> RECEIVE (<query>) search person RECEIVE (<person>) …, <person tel#=’…’>

3. Implementierung der Konzeption mit Java BEEP Bestandteil der BEEP Konzeption – Klassenabstraktion Channel ... sendMSG() getProfile() getSession() Message ... getChannel() getMsgno() getAnsno() sendMSG() sendRPY() sendANS() sendERR() sendNUL() Session ... startChannel() firedChannelClose() firedChannelStarted() firedChannelReceived() sendProfile() -zero channel -session Reply ... getNextReply() hasNext() receiveRPY() receiveERR() receiveANS() receiveNUL() TLSProfile Profile Init() ... Init()

3. Implementierung der Konzeption mit Java BEEP Client import org.beepcore.beep.core.*; import org.beepcore.lib.Reply; import org.beepcore.transport.tcp.*; ... public static void main (String args[]) { Session session; try { session = AutomatedTCPSessionCreator.initiate( "dragon", 8888, new ProfileRegistry()); } catch (BEEPException e) { // exception handling } Channel channel; channel = session.startChannel( "http://ibr.cs.tu-bs.de/fangming/ADDRESSBOOK"); //profile uri } catch (BEEPError e) { // catch and deal with errors System.out.print("error code: "+ e.getCode()); // catch lower level exceptions String message = "<person>"+ "<name>Fangming</name>" + "<tel>0049-531-2145611</tel>"+ "</person>"; ByteDataStream msgst = new ByteDataStream( request.getByes("utf-16")); msgst.setContentType("text/xml"); msgst.setTransferEncoding("utf-16"); Reply reply = new Reply(); channel.sendMSG(msgst, reply); while (true) { Message repmsg = reply.getNextReply(); DataStream ds = repmsg.getDataStream(); InputStream is = ds.getInputStream(); // the reply is a stream, not a string byte inputbuf[]=new byte[256]; int inputlen; String reptxt; while (ds.isComplete() == false || is.available() > 0) { inputlen = is.read(inputbuf); if (inputlen > 0) { reptxt = reptxt.concat(new String(inputbuf, 0, inputlen, "utf-16"); } System.out.println("got back:" +reptxt); Thread.currentThread.sleep(6000); } // end while } // end main

3. Implementierung der Konzeption mit Java BEEP Server public class AddressbookProfile implements Profile, StartChannelListener, MessageListener { ... public StartChannelListener init(String uri, ProfileConfiguration config) throws BEEPException { return this; } public void startChannel( Channel channel, String encoding, String data) throws StartChannelException { channel.setDataListener(this); public void closeChannel(Channel channel) throws CloseChannelException { channel.setDataListener(null); public void receiveMSG(Message message) throws BEEPError, AbortChannelException { DataStream ds = message.getDataStream(); AddressbookEntry newentry; String replytxt = "<person uid=\"" + String.valueOf(newentry.getUID()) + \""/>"; DataStream reply=new ByteDataStream( replytxt.getBytes("utf-16")); reply.setContentType("text/xml"); try { message.sendRPY(reply); } catch (BEEPException e) { // exception handling } ... } // end class AddressbookProfile

4. Zusammenfassung BEEP ist ein verbindungsorientiertes Protokoll und unterstützt die asynchrone Interaktion. Die ausgetauschten Daten werden mit XML kodiert. BEEP hat die Fähigkeit von Peer-to-Peer, Client-to-Server oder Server-to-Server. Der „Missbrauch“ von HTTP für Anwendungsprotokolle kann durch BEEP elegant abgelöst werden.