*********************************************** Selvitäpä tämä Juhanan SSCOP:ssa STAT_PDU :: decode laskee PDU:ssa olevat list_elementit jakamalla framen.length:n neljällä. Tästä seuraa, että kun testeri lähettää IVSTAT_PDU:n ja siellä on OCTETSTRING kenttä list_elementtien jälkeen viimeisenä (eli tekemässä PDU:sta invalid-tyyppisen), niin sen tunnistaminen SSCOP:Ssa voi mennä väärin. Adapterin en/dekoodaukset tälle PDU:lle eivät kiinnitä invalidiuteen mitään huomiota. Eli se ei huomaa mitään vääräksi PDU:ssa? *********************************************** Mietelmiä toteutuksesta: Pinon rakenne: Tester ------ ------ IDL taAdapter | XXX | CPCSadapter | ------------------------- taAdapter on adapteri, joka saa viestin (send) IDL-rajapinnalta ja lähettää siinä saadun datan eteenpäin (toA). Kun adapterin A-puolelle tulee viesti XXX:ltä (taMessenger), viesti tekee apply()-operaation tilassa ja kutsuu taMessengerAct-metodia. Tässä metodissa toteutetaan dekoodatun viestin lähetys (taMessenger->send) testerille tai jollekin vastaanottavalle palikalle. XXX on oma pfProtocol-tyyppinen protokolla, joka saatuaan viestin taAdapterilta (taMessenger), tekee saadun viestin sisältämälle datalle enkoodauksen (taMessengerAct) ja lähettää sen eteenpäin (toB) enkapsuloituna cpcsUNITDATAreq-viestiin. Toiseen suuntaan eli saatuaan viestin CPCS-adapterilta (cpcsUNITDATAind), XXX tekee dekoodauksen (cpcsUNITDATAindAct) saadulle framelle. Frame dekoodataan omaan rakenteeseen (otMessage::SerializedMessage) vastaanotetun SSCOP PDU:n tyypin mukaan. Dekoodattu viesti lähetetään taAdapterille (toB). XXX on periaatteessa tilaton protokolla, mutta frameworkin puitteissa tehtävät toteutukset kai vaativat ainakin yhden tilan, jotta kaikki toiminnallisuus saataisiin käyttöön. Tilassa toteutaan kaikki Act-metodit ja niiden mahdollisesti tarvitsemat apumetodit. Tarvitaanko tilalle joku oma messenger/transporter vai riittääkö taMessengerin välitys ylöspäin? Luultavasti ei tarvita omia messengereitä vaan em. taMessenger riittää. Eli tarvitaanko jotain omaa toiminnallisuutta? OK *********************************************** MIETELMIÄ DEKOODAUKSESTA: taMessengeriin ei (tietenkään) kannata rakentaa mitään protokollaspesifistä koodausta kiinni. Periaatteessa siihen voisi kirjoittaa yleiset en/dekoodausmetodit... Vai pitäisiköhän siihen periä jonkilainen kooderiluokka? Ei kuulosta järkevältä. Dekoodaus tehdään tilassa taMessengerAct()-metodista käsin. Varsinainen dekoodaus-metodi voi sijaita jossain muualla. Muissa protokollissa on tehty näemmä XXXmessenger::create(pfFrame)-metodi, jonka sisällä framesta luetun PDU:n tyypin perusteella dekoodaus tehdään jokaisessa messengerissä olevassa decode-metodissa. codingState :: taMessengerAct(taMessenger, pfProtocol) { ... otMessage::SerializedMessage msg = sscopPDUcoder::decode(frame); } OK *********************************************** Syitä storagen hylkäämiseen: * kenttien järjestys vääräksi (eli storage pistää kentät aakkosjärjestykseen) * encode menee ok, mutta decodessa suuria ongelmia: - eli decode tehdään tällä hetkellä PDU_Type:n mukaan. Kentän paikka on storagen vuoksi vaihtuva, jolloin joudutaan kikkailemaan tyypin selville saamiseksi - kentät, jotka ovat 2 tai 4 bittiä aiheuttavat framen lukuun suhteettomia ongelmia, koska framen getXXbits metodit toimivat oktettirajoin - "yleinen siisteys" eli MITÄHÄN TÄMÄ TARKOITTIKAAN??? Liian paljon koodia storagen kanssa?? * taMessenger :: taMessenger(string identifier_, const otMessage::SerializedMessage &message_) { . . . } *********************************************** Pinon rakenne client ----------------- printobject | | ----- IDL | send | ^ V | | send | | ------ IDL | send ------ IDL taAdapter ----------> taAdapter ------ ------ | | ------ ------ codingProtocol codingProtocol ------ ------ | | ------ ------ CPCSadapter CPCSadapter | ATM AAL5 | ----------------------------------------- Toteutus: Client ****** client lähettää komennolla send(string, otMessage::SerializedMessage) clientin koodissa muodostetun viestin. Viesti on koodattu tällä hetkellä käsin, jolloin siihen periaatteessa voidaan tyrkkiä mitä tahansa. Testitarkoituksiin kannattanee tehdä kaikkien PDU:den lähetys mahdolliseksi clientista. Clientillä implicit send -toiminta myös eli se voi lähettää IUT:n adapterille myös PDU:n. USSCF tai SSCOP käsittelee sen tällä hetkellä. taAdapter ******** pfTestAdapter luokassa luotaessa adapteria voidaan konstruktorille parametriksi pfState:sta peritty tila, jolloin adapteri saadaan reagoimaan siihen tuleviin viesteihin. Tätä on käytetty hyväksi pinon oikealla puolella, jossa taAdapter reagoi taMessengerihin (taState::taMessengerAct). Pinon vasemmalla puolella käytetään sendiä IUT:ltä vastaanotetun SSCOP PDU:n lähettämiseksi testerille. codingProtocol ************** Tässä protokollassa on yksi tila, joka enkoodaa yläpuolelta tulevista taMessengereistä otMessage::SerializedMessage:n pfFrameen, jonka se lähettää CPCSadapterille (taMessengerAct). CPCSadapterilta tulevista viesteista (cpcsUNITDATAind) dekoodataan pfFramessa oleva data ja muodostetaan siitä otMessage::SerializedMessage (cpcsUNITDATAindAct). CPCSadapter *********** CPCSadapterit hoitavat verkkoyhteyden. printObject *********** Tulostaa sille send-komennon mukana annettun otMessage::SerializedMessage:n eikä tee muuta. Tähän voi jotain toiminnallisuutta liittää mahdollisesti. Tällä print-toiminta on myös taMessengerissä, joten print on periaatteessa tarpeeton sscopserver *********** Sisältää CPCS:n, SSCOP:n ja USSCF:n, jotka on luotu saalConnection :: createUNIConnectionin avulla. USSCF on kiinni pfTestAdapterissa yläpuolelta ja siihen on kirjoittu (usscftate.h) taMessengerille oma Act-metodi, joka toteuttaa halutun toiminnallisuuden. VARMISTA VIELÄ IMPLICIT SENDIN OIKEA TOIMINNALLISUUS!!!!!!! Eli SSCOP:ssa on vaadituissa tiloissa toiminta OK, mutta USSCF saataa vielä vaatia viilausta, koska siinä ei kaikissa tiloissa impl. sendejä oteta huomioon. AJATTELUA TÄHÄN NYT!!!! *********************************************************************** Jos USSCF laitetaan SSCOP:n yläpuolelle, niin kuinka USSCF:ssä varmistetaan, että se on oikeassa tilassa? Eli src/protocol/usscf/usscfstate4_10.cpp: void usscfConnectionEstablished_DataTransferReady :: uaalESTABLISHreqAct(uaalESTABLISHreq *, pfProtocol *protocol_) { usscfProtocol *protocol = (usscfProtocol *)protocol_; protocol->sendAaRESYNCreq(); protocol->toUsscfAwaitingEstablish_OutgoingResynchronizationPending(); return; } Tässä tilassa uaalESTABLISHreq yläpuolelta aiheuttaa RESYNCreqin lähetyksen eikä aaESTABLISHreq kuten muissa tiloissa ja kuten testissä odotetaan. Standardi Q.2130 vaikuttaa siltä, että moinen käyttäyminen olisi kiellettyä, mutta paras varmistaa. *********************************************************************** Koodia implicit-sendin toteutusta varten tester | V taAdapter impl. send---> taAdapter | send(id, msg) | USSCF USSCF | | SSCOP SSCOP | | CPCS CPCS testAdapter lähettää taAdapter käsittelee viestin, jossa id kertoo halutun SSCOP-PDUn nimen. taAdapterissa tiedetään mikä signaali vaaditaan USSCF:ltä, jotta lähetys onnistuisi, tai sitten se tekee lähetyksen suoraan SSOCP:n avulla (RS ja POLL) PDU:t. *********************************************************************** sscoppducoder.cpp: Bittikenttien lukeminen pitäisi tehdä omassa metodissaan, koska koodissa on niin paljon toistoa. Header-tyyppejä on neljä erilaista, joille jokaiselle voisi olla oma metodi. TAI Tehdään oma metodi bittikenttien luvulle, jossa parametrina pelkästään luettavien bittien määrä. Jo olemassaolevan koodin perusteella moinen vaikuttaisi olevan mahdollista. TAI Yhdistetään edelliset eli kirjoitetaan kumpikin ja käytetään niitä kulloinkin kyseessä olevan headerin dekoodauksessa. Tässä metodissa voitaisiin periaatteessa hoita viestiin kirjoitus *KUNHAN* huomataan tehdä tämä oikeassa kohdassa suhteessa käsiteltävään frameen. OK *********************************************************************** implicit send-toiminta Eli halutaan saada IUT reagoimaan testerin haluamalla tavalla ja aloittamaan toiminta. Halutut PDU:t tilassa ja vastaavat primitiivit BGN - state1, state4 aaESTABLISHreq END - state2, state5, state10 aaRELEASEreq RS - state10 aaRESYNCreq POLL - state10 sscopPOLLtimeout SD - state10 aaDATAreq USSCF vastaavat tilat SSCOP - USSCF 1 - 1_1 BGN 2 - 2_2 END 4 - 3_4 BGN 5 - 2_5 END 10 4_10 END, RS, POLL, SD Constraintit POLL POLL_R_GEN | RS RS_R_GEN |sscop BGN BGN_R_GEN |VR_SQ viestistä, UU saa päättää END END_R_USER |UU saa päättää SD SD_R_GEN |VR_R viestistä, information saa päättää BGN voisi olla sscopstate.cpp:ssä aaESTABLISHreqAct() sscop:sta... Voi olla, että _VT_SQ:n joutuu tallettamaan. END voisi olla sscopstate.cpp:ssä aaRELEASEreqAct() ei pitäisi olla mitään ongelmia tämän hoitamisessa sscop:sta käsin SD aaDATAreqAct helppo, lähetys vain tilassa 10 ja yksinkertainen toiminta PENDING *********************************************************************** IMPL | SEND V ---------------> USSCF SSCOP_PDU SSCOP_PDU TESTER --------- SSCOP USSCF Implicit sendin toiminnan on saatava USSCF toimimaan oikealla tavalla tilassa ja tehtävä vastaavat toiminnat kuin impl. sendin oikeasti aikaansaava primitiivi tekisi. USSCF lähettää alaspäin saamansa taMessengerin, jonka sisältö on muuttumaton impl. sendissä tulleesta taMessengeristä. USSCF kuitenkin tarkastaa tulleen taMessengerin ja tekee yllä mainutut toiminnat sen tyypin perusteella, _paitsi_ varsinaista aa-primitiivin lähetystä. Eli SSCOP:lle menee taMessenger. USSCF:ssä toiminta vastaa vastaavan aa-primitiivin lähetyksen aikaansaavan uaal-primitiivin vastaanottoa paitsi, että vastaavaa aa-primitiiviä ei nyt lähetetä. SSCOP Implicit sendin yhteydessä SSCOP saa yläpuolelta USSCF:ltä taMessengerin, jonka vastaanottoon se reagoi joka tilassa aivan kuin olisi saanut USSCF:ltä aa-primitiivin. Eli SSCOP:n toiminta taMessengerin saatuaan vastaa aa-pritiivin vastaanottoa ja sen SSCOP:n toiminta on sama kuin primitiiviä vastaanotettaessa. SSCOP lähettää taMessengerissä vastaanottamansa sanoman eli SSCOP PDU:n viestistä dekoodatulla tavalla vastinoliolleen eli testerille. SSCOP voi näin ollen muuttaa prokollassa olevien muuttujiensa arvoja testerin haluamalla /edellyttämällä tavalla ja muuttaa niiden arvot takaisin samoiksi mitä ne olivat ennen kuin niitä muutettiin. HUOM!!! setSave ja allowDestroy!! setSaveToHead mielummin. Kaksisuuntainen send! eli Adapterin, joka yhdistää pinon pitäisi pystyä ensinnäkin sendin saatuaan lähettämään sieltä saatu viesti ja taMessengerin pinon alapuolelta saatuaan taMessengerAct-metodissa lähettämään testerille saatu viesti. Tämä vaatii, että adapteri tietää testerin olioviitteen. Se on saatu adapterille lukemalla se halutusta tiedostosta. getIOR-metodi on toimiva tämän toteuttamisessa. Ks. paperit kuvia varten. *********************************************************************** usscfState: POLL menee SSCOP:iin tilaan kymmenen. Missä tilassa USSCF:n pitää olla? Oletus: tila 4_10 ja tätä käytetään koodissa. Selkeää kopiokoodia sscopstateX.cpp tiedostoissa!! Tutkimuksen alla kuinka toteutusta voi selkeyttää tai tehdä kompaktimmaksi. Kopiokoodi on saapuvan taMessengerin kenttien arvojen siirtämisessä SSCOP-PDU:hin. Muuttujien arvojen asettamisen toimiminen SSCOP:ssa on epävarmaa. Tämä johtunee enemmän koodin suorasta kopioinnista ja myöhäisestä kellonajasta kuin siitä, että se ei ideana olisi toimiva. Olisi ehkä ollut helpompaa kirjoittaa aaXXXAct-metodien koodi suoraan vastaavaan sscopstateX:n taMessengerAct -metodiin, mutta arvelin, että noiden käyttö saataa kuitenkin toimia, jos vastaanotetun taMessengerin arvot siirretään tarvittaviin kenttiin. KOPIOKOODI tässä. taMessengerAct-metodi usscf:n tilassa 2_5 lienee tarpeeton. On tällä hetkellä pelkkä return, mutta poisto pitää varmistaa. SSCOP:ssa ja USSCF:ssa on state.h:ssa common/error.h ja pf/debug.h, jotka pitäisi siirtää kuhunkin tilaluokkaan, missä niitä erikseen tarvitaan. taMessengerAct on tilojen kantaluokassa pelkkä return, kaikki toiminnallisuus on toteutettu kussakin tilassa erikseen. *********************************************************************** 13.7.1998: vmp:n kanssa keskustellut ja katsotut korjaukset: - dynamic_cast & THROW_ ... tavallisten tilalle - Fileheader kuntoon kaikilta osin - käytäntö .ref -tiedostojen nimeämiselle - print-toiminnon voisi integroida adapteriin ja samalla katsoa miten taMessenger voisi olla apuna tässä (ja mahdollisesti koodia storagesta) - kielletään/tarkastetaan explisiittisesti usscf:ssä implicit send PDU:den lähetykset - codingprotocol kuuluu /sscop-hakemiston alle, ei adapterin - codingprotocol ja -state yhteen (vmp tehnyt muutoksen pfProtocoliin) - clientissä orb_ptr orbSchedulerin avulla eikä kuten muualla on tehty kutsumalla orbInit ja muita metodeja - tulostus näyttää koko PDU:n - const stringit mihin kuuluu *********************************************************************** MUUTOKSIA yleinen - descriptioniin lisätty PDU:n kuvaus yleinen - siirretty decodeListElement pducoderbasesta sscoppducoderiin sscoppducoder.cpp decode - poistettu PDU-lengthin tarkistus sscoppducoder.h SSCOP_MN_PDU_LENGTH poistettu kummastakin pducoderbase.cpp Liian lyhyet kentät hoidetaan decodeXXFromFrame-metodeissa laittamalla otMessage::SerializedMessageen tyhjä ("") kenttä. HUOM! Ei taida toimia Booleanille ja Integerille. Vai pitäiskiö lopettaa viestiin pistäminen täysin tällaisissa tapauksissa. *********************************************************************** Makefile siistimmäksi jossain vaiheessa *********************************************************************** MITEN hoidetaan SSCOP:ssa ja erityisesti USSCF:ssä implicit send??????? Pitääkö USSCF:n reagoida joka tilassa siihen tuleviin taMessengereihin ja katsoa, missä tilassa SSCOP ja toimia kuten oltaisiin oikeassa tilassa. Eli esim. jos USSCF-tilassa 4_10 tulee BGN impl. send niin lähetetäänkö SSCOP:lle eteenpäin RS, jonka se ymmärtää BGN:n lähettämiseksi? Ei kai. *********************************************************************** Operaatiot: 6 kpl kaikki koodi on pseudoa ja alustavaa ajattelua/mietintää. INC_MOD_8(parIN, amount:INTEGER) ******************************** Palauttaa parIN:n ja amount:n summan modulo8:n... return (parIN+amount) % 8; // SM:n mukana. Mitenhän kentän nimi tms? INC_MOD_24(parIN, amount:INTEGER) ********************************* Palauttaa parIN:n ja amount:n summan modulo24:n... return (parIN+amount) % 24; // SM:n mukana. Mitenhän kentän nimi tms? GET_VR_MR ********* asetetaan VR_MR. Palauttaa INTEGER:n, jossa VR_MR:n arvo. Alussa voisi olla esim. 2^24 tai joku tarpeeksi iso. integer ISOLUKUJOSTAIN=2^24; (eli 16777215) return ISOLUKUJOSTAIN; // SM:n mukana. Mitenhän kentän nimi tms? CHECK_N_PS(parPA, parN_PS, parPS) ********************************* Onko N_PS validi vai ei. Palauttaa Booleanin sen mukaan. boolean returnValue=false; if (parN_PS > parPA && parN_PS < parPS) { returnValue = true; } return returnValue; // SM:n mukana. Mitenhän kentän nimi tms? APPEND_LIST(parLIST:LIST_TYPE,parLE:INTEGER) ******************************************** Käyttö esim. S1_IV_I27_2 testispeksistä: 1. Make an instance of LIST_ELEMENT_TYPE (parLE 24 bitString ja PAD "00"O) Eli tässä listan alkiot tulee jokainen erikseen ParameterList tyyppiä olevan listan alkioissa, jotka ovat SerializedMessage-tyyppiä while (int i++ < ParameterList.length) otMessage::SerilizedMessage tmp = ParameterList[i] otMessage::SerilizedMessage final[k].id/.kind./value./number = tmp.id/.kind./value./number //nyt append int len = final.length()+1; final.length(len+1); final[len+1].id/.kind./value./number= /LE/otMessage::BitString/IntegerToBitString(parLE)/0 /PAD/otMessage::OctetString/"OO"/0 2. append to existing parLIST Muodostetaan ParameterListasta SerializedMessage... Vai mitenkähän? Kikkailua LE-kentän kanssa voi joutua harrastamaan, jos nimeksi vaaditaan jotain muuta kuin LE. 3. return the new list Palautetaan SerializedMessage send2way:n mukaan. GEN_OCTET(parLEN:INTEGER) ************************* Luo parLENin pituisen octetstringin ja palauttaa sen. Java.string octetString; for ( int i=0; i<2*parLEN; i++) { octetString +="O"; } return octetString; *********************************************************************** Testauksessa käytetty #ifdef direktiivi on -D__SSCOP_TESTING__ Tämä pitää määrittää jotenkin usscf:n ja sscop:n Makefileissä. Tällä hetkellä olen käyttänyt Rules.Makessa olevaa FSR_DEFS muuttujaa, kummassakin, sillä se näkyy sscop:lle ja usscf:lle asti. Eli Makefilessa näin #### Makefile alkaa FSR_DEFS = -D__SSCOP_TESTING__ ARTARGET = sscop.a ... #### Makefile loppu Asialle voisi sopia tietysti omankin definen Rules.Makeen mutta tällä hetkellä asia saadaan hoidettua näinkin. *********************************************************************** DEBUG: TRACE: starting name comparison... : usscfstate1_1.cpp : 111 DEBUG: TRACE: UH-OH comparison unsuccessful... : usscfstate1_1.cpp : 133 DEBUG: TRACE: String was = string : RS_PDU : usscfstate1_1.cpp : 134 DEBUG: TRACE: Messenger was NOT destroyed in ~pfMsgTransporter : transp.cpp : 336 DEBUG: END_RUNNING Muistivuotoa näyttäisi myös ps:n mukaan tapahtuvan. Noin 15 kiloa/100 viestiä. Jäljitys päällä. Ja näyttäis johtuvan siitä, että messengeriä ei todellakaan tuhota esim. usscfConnectionReleased_Idle :: taMessengerAct -metodissa, vaikka pitäisi. *********************************************************************** Alla huomioita debug-tulostuksesta sscoptestauksen yhteydessä. Kommunikoivat osapuolet ovat server ja sscopserver Encode-tulostus tapahtuu vain lähetettäessä (luonnollisesti). 1. pfTestAdapter :: send DEBUG: TRACE: PDU identifier = string : BGAK_PDU : taprimitives.cpp : 176 DEBUG: TRACE: id = string : UU : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 6 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 0000000000 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : PAD : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 6 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 000000 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : RESERVED : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 6 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 00000000 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : PL : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 4 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 11 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : RSVD : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 4 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 00 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : PDU_Type : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 4 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 0010 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : N_MR : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 4 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 000011110000111111110000 : taprimitives.cpp : 192 DEBUG: SENDING_TO_A: taMessenger_34 DEBUG: RECEIVING: codingProtocol receives taMessenger_34 DEBUG: START_RUNNING: codingProtocol runs taMessenger_34 2. pduCoderBase :: encode DEBUG: TRACE: BitString = string : 000011110000111111110000 : pducoderbase.cpp : 97 DEBUG: TRACE: BitString = string : 0010 : pducoderbase.cpp : 97 DEBUG: TRACE: BitString = string : 00 : pducoderbase.cpp : 97 DEBUG: TRACE: BitString = string : 11 : pducoderbase.cpp : 97 DEBUG: TRACE: OctetString = string : 00000000 : pducoderbase.cpp : 101 DEBUG: TRACE: OctetString = string : 000000 : pducoderbase.cpp : 101 DEBUG: TRACE: OctetString = string : 0000000000 : pducoderbase.cpp : 101 DEBUG: SENDING_TO_A: cpcsUNITDATAreq_36 DEBUG: RECEIVING: cpcsATMAdapter receives cpcsUNITDATAreq_36 DEBUG: END_RUNNING DEBUG: START_RUNNING: cpcsATMAdapter runs cpcsUNITDATAreq_36 DEBUG: END_RUNNING DEBUG: SENDING_TO_A: cpcsUNITDATAind_37 DEBUG: RECEIVING: codingProtocol receives cpcsUNITDATAind_37 DEBUG: START_RUNNING: codingProtocol runs cpcsUNITDATAind_37 3. sscopPduCoder :: decode DEBUG: TRACE: decodeENDpdu!!! : sscoppducoder.cpp : 230 DEBUG: SENDING_TO_B: taMessenger_38 DEBUG: RECEIVING: pfTestAdapter receives taMessenger_38 DEBUG: END_RUNNING DEBUG: START_RUNNING: pfTestAdapter runs taMessenger_38 4. taMessenger :: printData DEBUG: TRACE: PDU identifier = string : END1 : taprimitives.cpp : 176 DEBUG: TRACE: id = string : RESERVED1 : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 6 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 00000000 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : PL : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 4 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 00 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : RR : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 4 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 0 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : S : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 4 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 1 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : PDU_Type : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 4 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 0011 : taprimitives.cpp : 192 DEBUG: TRACE: id = string : RESERVED2 : taprimitives.cpp : 183 DEBUG: TRACE: kind = pfUlong : 6 : taprimitives.cpp : 184 DEBUG: TRACE: value = string : 000000 : taprimitives.cpp : 192 DEBUG: END_RUNNING time make ajettu sscop:ssa antaa seuraavan tuloksen 46.320u 40.190s 2:49.10 51.1% 0+0k 0+0io 66406pf+0w *********************************************************************** Toisessa ympäristössä kääntö: make clean ; make idl ; make dep ; make HUOM! make idl ja make dep auttavt ohittamaan ison kasan ongelmia. taprimitives.h: #include #include hupussa ainakin muutettava muotoon: #include #include msg_impl.cpp ja tastate.cpp käyttävät errno:a koodissa --> kommentoitava pois!! // extern int errno; cerr << "can't open in taState:" << filename_ << endl; //"': " << strerror(errno) << endl; // exception ? Kääntäjä valittaa seuraavaa: TESTING__ -g -Wall -pedantic -frtti server.o sscoppducoder.o codingprotocol.o /root/tove+OB/src/protocol/cpcs/cpcs.a /root/tove+OB/src/iface/cpcsif/cpcsif.a /root/tove+OB/src/iface/uaalif/uaalif.a /root/tove+OB/src/common/common.a /root/tove+OB/src/pf/pf.a /root/tove+OB/src/sf/sf.a ../adapter/codinglib.a /usr/local/lib/libOB.a ../adapter/codinglib.a(msg_impl.o): In function `pfTestAdapter::saveIOR(CORBA_ORB *, basic_string, __default_alloc_template > const &)': /root/tove+OB/src/testing/testadapter/adapter/msg_impl.cpp:136: undefined reference to `__errno_location(void)' ../adapter/codinglib.a(tastate.o): In function `taState::getIOR(CORBA_ORB *, char *)': /root/tove+OB/src/testing/testadapter/adapter/tastate.cpp:115: undefined reference to `__errno_location(void)' collect2: ld returned 1 exit status Kuulemma tulee muillakin kääntäessä. Ongelmaa ei ole sen ihmeemmin jäljitetty. Ja sitten jotain täysin mystistä: sscop/client.cpp client.cpp: In function `class OBVarSeq decodeSSCOPpdu(class pfFrame)': client.cpp:591: warning: unused variable `enum otMessage::ElementKind kind' client.cpp: In function `class OBObjVar readOneRef(char *, class OBObjVar)': client.cpp:636: parse error before `return' client.cpp:637: warning: didn't find handler for EH region 4009 client.cpp:637: warning: didn't find handler for EH region 4011 client.cpp:637: warning: didn't find handler for EH region 4027 client.cpp:637: warning: region exists, no handler 4009 client.cpp:637: warning: region exists, no handler 4011 client.cpp:637: warning: region exists, no handler 4027 client.cpp:637: warning: region exists, no handler 4027 client.cpp:637: warning: region exists, no handler 4011 client.cpp:637: confused by earlier errors, bailing out make: *** [client.o] Error 1 NIIN ETTÄ MITÄHÄN TÄSSÄ TAPAHTUI??!! try - catch parista puuttui se catch. *********************************************************************** 31081998 Mietelmiä IUT:n hukkaamien END-PDU:den kohtalosta: Tällä hetkellä vaikuttaisi lähinnä siltä, että vika sijaitsee CPCS-adapterissa, joka ei osaisi puskuroida PDU:ita, jos se saa niitä liian nopeasti tai se jää johonkin määrittämättömään tilaan tämän tapahtuessa. sscopserver.log antaa seuraavan virheilmoituksen TRACE:ssa: 745 DEBUG: TRACE: cpcsActiveState :: cpcsUNITDATAreqAct: writeDevice failed : cpcsastate.cpp : 101 746 DEBUG: END_RUNNING 747 DEBUG: TRACE: TIMESTAMP: Thu Aug 27 10:25:06 1998 904202706 sec 152422 u 747 sec : debug.cpp : 249 748 DEBUG: START_RUNNING: 14cpcsATMAdapter runs 15cpcsUNITDATAreq_49 749 DEBUG: RECEIVING: 14cpcsATMAdapter receives 15cpcsUNITDATAreq_50 750 DEBUG: TRACE: cpcsActiveState :: cpcsUNITDATAreqAct: writeDevice failed 750 : cpcsastate.cpp : 101 751 DEBUG: END_RUNNING 752 DEBUG: TRACE: TIMESTAMP: Thu Aug 27 10:25:06 1998 904202706 sec 177295 u 752 sec : debug.cpp : 249 753 DEBUG: START_RUNNING: 14cpcsATMAdapter runs 15cpcsUNITDATAreq_50 754 DEBUG: END_RUNNING Tämän on paikannettu tulevan sscopOutgoingDisconnectionPending :: sscopBGNpduAct-metodin jälkeen. Metodissa tehdään kahden PDU:n lähetys peräkkäin: 136 protocol_->sendBGAKpdu(emptyFrame); 137 protocol_->resendLastENDpdu(); protocol/cpcs/cpcsastate.cpp cpcsActiveState :: cpcsUNITDATAreqAct : ... if (adapter->writeDevice(frame) != 0) { ... writeDevice palauttaa nollan: pfBoolean pfDevice :: writeDevice(pfFrame &frame_) { pfBoolean failure = 0; if (_writePending != 0) { // previous write wasn't completed. we cannot queue requests failure = 1; } else { ... Jotain hassua tuntuu olevan tekeillä, sillä lokit näyttävät BGNAK:n menevän ok (eli se näkyy forwarderilla, mutta sen jälkeen kaikki IUT:n lähettämät PDU:t katoavat ja lähetys onnistuu vasta sen jälkeen kun, vastapää (tester) lähettää PDU:n sen timereiden lauettua.