Delphi Linux REST-Daemons fyrir fyrirtæki: Arkitektúr, rekstur og viðhaldshæfni í framkvæmd

Þegar fyrirtæki tala í dag um nútímavæðingu snýst það sjaldan um „allt nýtt“. Oft er markmiðið að færa trausta rökfræði, gagnalíkön og ferla yfir í stöðugt, vel rekjanlegt þjónustulag – án þess að ógna daglegum rekstri. Einmitt hér eru Delphi Linux REST-Daemons für Unternehmen hagstæð lausn: þeir gera kleift að reka varanlega þjónustusamhengi undir Linux, bjóða skýrar HTTP/REST-viðmótsfleti (vef-API yfir HTTP, oft með JSON sem gagnasniði) og fara inn í rekstrarstaðla eins og systemd, reverse proxies, miðlæga skráningu og CI/CD.

Greinin beinist að IT-stjórnendum, kerfisstjórum og tæknilegum verkefnisstjórum. Í brennidepli eru áhrif á rekstur, stjórnun, gögn og viðmót: Hvernig fæst viðhaldshæfur arkitektúr? Hvernig er útgáfunúmerum API stjórnað? Hvernig eru uppfærslur rullaðar út á stjórnaðan hátt? Hvernig er þjónustum styrkt, vaktað og afmarkað þegar bilun kemur upp? Og hvernig fellur þetta að fyrirliggjandi landslagi með gagnagrunnum, ERP/DMS/CRM-tengingum, auðkenningum og öryggiskröfum?

Delphi Linux REST-Daemons fyrir fyrirtæki í rekstri

REST-Daemon er langvarandi bakgrunnsferli (á Linux sem „Daemon“) sem tekur við HTTP-fyrirspurnum og svarar þeim. Í fyrirtækjarekstri er þetta oft brúin milli fyrirliggjandi viðskiptareglna og nýrra neytenda: vefgáttir, farsímaforrit, samþættingar, samstarfstengingar eða innri sjálfvirkni.

Linux hefur fest sig í sessi sem server-plattform hjá mörgum fyrirtækjum: auðvelt að sjálfvirkja, gagnsætt í kerfisstjórnun og aðgengilegt í VM-, container- eða hefðbundnum hýsingaruppsetningum. Mikilvægara er þó ekki svo mikið „Linux sjálft“ sem þjónustulíkanið: skilgreind ræs/stöðvun, reglur um endurræsingu, aðgangsréttakerfi, tenging við skráningu og skýrt uppfærsluferli.

Delphi nýtir styrkleika sína í þeim tilfellum þar sem þegar er til undirstaða: staðfest fagleg rökfræði, uppsöfnun gagnaaðganga (oft í gegnum BDE-Ablosung mit nativer Anbindung sem gagnaaðgangslag), sértæk samskiptaprotókól (t.d. TCP/IP eða skrármót) og langárig prófuð reglur. Linux-REST-Daemon gerir kleift að bjóða þessa rökfræði sem þjónustu án þess að endurvinna hana frá grunni. Fyrir marga nútímavæðingarleiðir þýðir það að komast hraðar að áreiðanlegum endapunktum, en samt skipuleggja arkitektúr og rekstur frá upphafi á vandlega hátt.

Algengar notkunarsenur fyrir Delphi Linux REST-Daemons í fyrirtækjum

Í verkefnum koma aftur og aftur fram ákveðin mynstr. Linux-REST-Daemon er sjaldan „bara API-þjónn“, heldur hluti af heildararkitektúr með skýrum ábyrgðum:

• API-lag fyrir eldri hugbúnað: Núverandi skrifborðs- eða client-server-lausn fær REST-API svo vefgáttir, nýir viðskiptavinir eða ytri kerfi geti fengið staðlaðan aðgang.
• Samskipti og orkestrering: Daemon tengir ERP, DMS, CRM og sérhæfða íhluti. REST er stöðug ytri hlið; innanhúss má nota biðraðir, skrármót eða einkabundnar gáttir.
• Vinnuflæði nálægt ferlum: Staðfestingar, samþykktir, stöðubreytingar, skjalsköpun eða skýrslugerð sem miðlæg þjónusta með rekjanlegu hegðun.

Viðbótargildi myndast ekki vegna „REST“ sem slagorðs, heldur vegna stöðugra viðmótssamninga, stjórnaðs gagnaaðgangs og trausts rekstrarlíkans.

Grunnatriði arkitektúru: Lög, samningar, gagnasamkvæmni

Algengur vandi í þjónustuverkefnum er að einblína á „að afhenda endapunkta hratt“, á meðan útgáfustjórnun, villuháttur, skráning og gagnasamkvæmni eru seinna bætt við með erfiðismunum. Fyrir rekstur skiptir skýr lagaskipting meira máli en tiltekið bókasafn.

Lagaskiptingarmódel (Layer-3): API, dómasvið, innviðir

Raunhæft Layer-3‑arkitektúr (þrjú lög til að stjórna háðum) aðgreinir venjulega eftirfarandi:

• API‑lag: HTTP‑endapunktar, auðkenning/heimild, beiðnistaðfesting, svarformöt, villukóðar.
• Dómasvið: Fagreglur og vinnuflæði, stöðulíkön, athuganir, ákvarðanir um réttindi – án þekkingar á HTTP.
• Innviðir: Aðgangur að gagnagrunni (t.d. BDE-Ablosung mit nativer Anbindung), ytri kerfi, skrárakerfi, tölvupóstur, raðir, leyndarupplýsingar og stillingar.

Þessi aðskilnaður er í daglegu viðhaldi mikilvægur viðhaldsþáttur: hann kemur í veg fyrir að API‑upplýsingar síist inn í faglega rökfræði og dregur úr aukaverkunum þegar gagnagrunnur, auðkenningarkerfi eða proxy eru síðar breytt.

Samningar: JSON‑líkön, villuskipulag, idempotentleiki

REST byggir á stöðugum samningum. Fyrir rekstur og samþættingu skiptir það sköpum að svör séu áreiðanleg og véltúlkanleg. Til þess teljast:

• Samkvæm villuskipulag: Ekki aðeins „500“, heldur véltúlkanlegir villukóðar, skiljanleg skilaboð og stuðningsupplýsingar án viðkvæmra gagna.
• Idempotentleiki: Endurteknar beiðnir (t.d. eftir tímamörk) mega ekki valda tvöföldum færslum. Fyrir mikilvægar aðgerðir hjálpa idempotency‑lyklar eða skýr stöðu‑ og afritskoðun.
• Stöðugar gagnagerðir: Dagsetninga‑/tímasnið, aukastafir desimaltalna, talnagildi (t.d. stöðugildi) verða að vera langtímalega stöðug.

Markmiðið er samþættingaröryggi: Vefviðmót, samstarfsaðili eða innra sjálfvirkniskrift þarf að geta haldið áfram að keyra á stjórnaðan og áreiðanlegan hátt eftir uppfærslu.

Samhliða úrvinnsla og verndarrahmar: Pooling, tímamörk, takmörk

Daemon vinnur beiðnir í samhliða úrvinnslu. Fyrir rekstur eru auðlindatakmörk og varnarmekanismar mikilvægir svo truflanir nái ekki að stækka:

• Connection‑Pooling: Tengingar við gagnagrunn eru dýrar. Pool verndar gegn álagstoppum og kemur í veg fyrir að hver beiðni neyði fram „nýja tengingu“.
• Tímamörk: Fyrir gagnagrunns aðgang, ytri HTTP‑köll og innri verk þarf að skilgreina hörð mörk svo seinkun smitist ekki áfram.
• Rate Limiting: Vörn gegn rangri stillingu eða stjórnlausum viðskiptavinum; oft innleitt í reverse proxy.
• Backpressure: Ef eftirfylgni kerfa er hæg þarf þjónustan að hafna beiðnum eða biðraða þær á stjórnandi hátt í stað þess að taka á móti ótakmarkað.

Þessir þættir ráða oft hvort þjónusta helst stöðug undir álagi eða hvort einstaka þröskuldar loka fyrir allan rekstur.

Linux‑rekstrarlíkan: systemd, aðgangsréttindi, skráning

Á Linux er systemd í flestum dreifingum staðlaður þjónustustjóri. Ein systemd-þjónusta skilgreinir hvernig ferli byrjar, hvenær það er endurræst, hvaða háðir eru til staðar og undir hvaða réttindum það keyrir. Fyrir stjórn og rekstur er þetta lykilatriði fyrir áreiðanleika.

systemd í framkvæmd: Restart-Policy, Abhängigkeiten, Shutdown

Traustur rekstur hefst með ræsinga- og endurræsinga-stefnu sem tekur tillit til raunsærra villusena:

• Restart-Policy: stýrð endurræsinga við hnignun, með mörkum til að koma í veg fyrir endalausa endurræsingu.
• Abhängigkeiten: ræsa aðeins þegar netið er tilbúið; ef þörf krefur, skilgreind röð í tengslum við aðrar þjónustur.
• Graceful Shutdown: við stop/endurstart skulu laufandi beiðnir vera lokið snyrtilega og transaktionar kláraðar.

Skýr Health-Endpunkt (t.d. /health) hjálpar eftirliti og Load Balancer. Skynsamlegt er að greina á milli „ferlið lifir“ og „þjónustan tilbúin“ (t.d. gagnagrunnur aðgengilegur), án þess að keyra dýrar fyrirspurnir í Health-Check.

Least Privilege: eigener Service-User und restriktive Zugriffe

Öryggi í rekstri er ekki bara TLS. Dæmon ætti að keyra með lágmarksréttindum:

• Eigener Linux-User: ekki keyra sem root; aðgangur aðeins að nauðsynlegum möppum.
• Secrets trennen: aðgangsupplýsingar eiga ekki heima í Deploy-Skripten eða Loggs, heldur í varinri stillingu eða í Secrets-kerfi umhverfisins.
• Port-Modell: þjónustan bindur sig innra neti við hátt port; ytri aðgangur er veittur í gegnum Reverse Proxy/Load Balancer.

systemd er hægt að herða enn frekar (t.d. takmarkaður aðgangur að skráarkerfi). Hversu langt það nær fer eftir rekstrarforskriftum, gámavæðingu og dreifingu – grundvallarreglan stendur: halda heimildum meðvitað litlum og gera breytingar rekjanlegar.

Logging: journald, strukturierte Ereignisse und Correlation-ID

Fyrir stuðning og atvikagreiningu er skráning mikilvægasti greiningarásinn. Í Linux-umhverfum endar margt í journald (systemd-Journal) og er þaðan áfram sent í miðlæg kerfi (eftir staðli, t.d. Elastic/OpenSearch, Graylog eða Splunk).

Það skiptir máli að loggar séu uppbyggðir og leitarhæfir: Request-ID/Correlation-ID (einstakt auðkenni fyrir hverja beiðni), notenda-/leigutaka-samhengi, Endpoint, keyrslutími, stöðukóði, villukóði. Þannig má rekja vandamál frá Reverse Proxy, í gegnum dæmoninn og til gagnagrunnsins.

Einnig er gagnahreinlæti mikilvægt: engin lykilorð, Tokens eða óstýrð persónugreinanleg gögn í loggum. Fyrir nánari upplýsingar eru faglega viðeigandi Audit-Daten (sjá neðar) oft betri staður.

Security und Zugriffskontrolle: Reverse Proxy, TLS, SSO, Rollen

Ein REST-Daemon er viðmót út á við og þannig hluti af árásarflöt. Í fyrirtækjaumhverfum reynist góð arkitektúruppsetning vera sú að ekki sé „allt í þjónustunni“, heldur séu ábyrgðir skýrlega skilgreindar.

TLS-Terminierung am Reverse Proxy

Oftast er TLS (HTTPS-dulkóðun) lokið hjá Reverse Proxy eða Load Balancer, ekki í þjónustunni. Kostir: miðlæg skráning vottorða, samræmdar Security-Policies, einfaldari snúningur (Rotation), einangraðir Access-Logs og valfrjálsar WAF-/Rate-Limiting-aðgerðir.

Dæmoninn keyrir á innra einkanetssvæði. Mikilvægt er rétt meðhöndlun Forwarded-Headern (t.d. raunveruleg Client-IP): slíka hausar má aðeins samþykkja frá traustum uppsprettum, annars skapast spoofing-hættur.

Auðkenning og heimild: OIDC eða SAML 2.0

Fyrirtæki gera kröfu um Single Sign-on (SSO) og miðstýrð auðkenni. Tæknilega fer það oft fram í gegnum OpenID Connect (OIDC, token-bundið) eða SAML 2.0 (XML-bundið SSO-samskiptaprotokoll, komið fyrir í mörgum enterprise-umhverfum). REST-daemoninn á ekki að „finna upp“ eigin notendastjórnun heldur að taka við auðkenningum og kortleggja aðgangsheimildir með hlutverkum og claims (úthlutningar í token).

Fyrir rekstur eru venjulega þrír punktar mikilvægir:

• Token-lífslengd: stutt access-tokens, skilgreind meðferð við útrun og refresh hjá client.
• Service-to-Service aðskilja: vélaraðgangar með eigin auðkennum og sértækum réttindum, hreint aðskilin frá notendaaðgengi.
• Hlutverkalíkan með lágmarksréttindum: skilgreina réttindi fyrir hvern use case svo samþættingar verði ekki of mikilsvirkar.

Auditing: fagleg rekjanleiki

Mörg ferli krefjast rekjanleika: Hver breytti hvaða stöðu? Hvaða viðmót flutti inn gögn? Slík gögn eiga heima í uppbyggðum audit-trail (mögulegt að vinna faglega úr), ekki eingöngu í tæknilegu loggi. Loggið þjónar greiningu; auditing er fagleg saga og þarf að vera mótuð og varin sem slík.

Aðgangur að gögnum og gagnagrunnar: atómískar aðgerðir, gagnaflutningar, stöðugleiki

Í Delphi-verkefnum er FireDAC oft miðlæg tækni fyrir gagnaaðgang. Fyrir IT-ábyrgðarmenn skiptir spurningu um starfsemi meira máli en Query-syntax: viðskiptajörð, læsingar, migrationar, frammistaða, endurheimtanleiki og skýr ábyrgð á schema.

Transaktionsgrenzen und sauberes Fehlerverhalten

Svör við REST-beiðnum þurfa skýrar transaktionsmörk: breyting verður annaðhvort fullkomlega staðfest eða hreint afturkallað. „Helmingstillfelli“ refsa sér í samþættingum því eftirfölgjandi ferlar byggja á ósamræmdum gögnum.

• Stuttar transaktionir: engar langvarandi læsingar yfir netköllum til ytri þjónustu.
• Optimískt samkeppnisstýring: útgáfu-/RowVersion-reitur til að greina samhliða breytingar.
• Skýr viðbrögð við árekstrum: t.d. skilgreindir „Conflict“-villukóðar í stað almenns 500 svarskóða.

Schema-Änderungen: Deployment und Datenbankmigration zusammen denken

Gagnalíkön breytast. Mikilvægast er hvernig þjónustudreifing og gagnagrunnsmigration samhæfast. Gott vinnulag er að meðhöndla migrationar sem númeruð skref (með fyrirvara um rollback) og byggja þjónustur þannig að þær þoli tímabil þar sem bæði gamla og nýja byggingin eru til staðar. Þetta gerist oft með viðbætum (nýir dálkar/töflur) fremur en tafarlausri endurnefningu eða eyðingu.

Ritstjórnlega er þarna gott að tengja inn ítarleg efni um gagnabreytingar og vegi til nútímavæðingar, því þessi mál teljast í reynd saman.

Performance-Schutz: Paging, Statement-Timeouts, Pool-Auslastung

Margar REST-áskoranir rekja má til gagnagrunnsvandamála: vantar vísunaryfirlykill (indexes), ótamdar leitarfyrirspurnir, of stór resultset eða óhagstæð læsingartilfelli. Fyrir rekstur hjálpa varnarbremsur:

• Paging/Limit: enda punktar ættu ekki að skila „öllu“, heldur vera pagineruð.
• Statement-Timeouts: fyrirspurnir verði að hætta áður en þær stífla poolinn.
• Prófa skalann: Meta fyrirspurnir ekki aðeins með prófunargögnum heldur með raunsæjum gagnamagni.

Hönnun API fyrir langtíma samþættingar: REST API-útgáfustjórnun og OpenAPI

Um leið og portal, BI-ferli eða samstarfsaðili er samþættur, verða brotbreytingar að rekstrarlegum áhættuþáttum. Þess vegna er API-hönnun rekstrarleg ákvörðun, ekki aðeins þróunarmál.

REST API-útgáfustjórnun: Reglur frekar en „v2 einhvern tímann“

Útgáfustjórnun er ekki bara tala í slóðinni. Hún er ferli: Hversu lengi verður útgáfan studd? Hvernig eru neytendur upplýstir? Hvernig er eftirnotkun mæld?

• URL-útgáfustjórnun (t.d. /v1/…): auðskiljanlegt, hentugt fyrir útgáfur sem keyra samhliða.
• Header-útgáfustjórnun: tæknilega mögulegt, en í sumum verkfærakeðjum minna gagnsætt.
• Gefið forgang viðbótarbreytingum: nýir reitir, nýir endapunktar, valfrjálsir parametrar í stað brotbreytinga.

Til útgáfustjórnunar telst stefna um úreltun: Gamlar útgáfur eru teknar úr notkun með tímafresti, samskiptum og eftirliti – ekki óvænt slökkt á þeim.

OpenAPI sem sameiginlegur rekstrar- og samþættingagrunnur

OpenAPI (oft sýnilegt í gegnum Swagger-UI) er í rekstri gagnlegt artefakt ef það er rétt viðhaldið: endapunktar, reitir, villur, auðkenningarskjema. Þetta dregur úr fyrirspurnum, flýtir fyrir samþættingum og skapar sameiginlegan stöðupunkt milli reksturs, fagsviðs og útfærslu.

Gildi myndast með aga: skjalfesta samninga, gera breytingar rekjanlegar og prófa samhæfni markvisst.

Dreifing og uppfærslur án stöðvunar: Blue-Green, Rolling, Rollback

Í fyrirtækjarekstri er deployment stjórnað ferli með hliðsjón af tiltækt, gagnaintegriteti og afturfallsvalkostum. Sérstaklega REST-Daemons eru fljótt notaðir af mörgum kerfum; ósamstilltar uppfærslur valda samþættingatruflunum.

Aðskilja útgáfupakka og stillingar

Traust deployment aðskilur forritsútgáfu og stillingar. Stillingar ná yfir gagnagrunnstengingar, endapunkta ytri kerfa, feature-flags, log-stig og vísanir í leyndarmál. Jafnframt er umhverfisjafngildi mikilvægt: Dev/Test/Prod ættu að líkjast uppbyggingulega svo villur verði ekki fyrst sýnilegar í framleiðslu.

Hvort sem sem deb/rpm, artefakt-dreifing í gegnum CI/CD eða container-image: það sem skiptir máli er rekjanleiki. Rekstrarteymi verða að geta svarað: Hvaða útgáfa keyrir hvar, með hvaða stillingum, og hvaða migreringar voru framkvæmdar?

Blue-Green og Rolling Updates

Fyrir háan tiltækileika hafa tvö mynstur fest sig í sessi:

• Blue-Green Deployment: gamla og nýja umhverfið keyra samhliða, umstilla á load balancer. Kostur: hraður rollback. Forsenda: gagnagrunnsbreytingar verða að vera samhæfar.
• Rolling Updates: margar instansar eru uppfærðar ein af annarri. Kostur: ekki þarf tvöfalt uppsetning. Forsenda: blandað ástand (gamalt/nýtt) er tímabundið óhætt.

Í báðum tilvikum er API-samhæfni lykilatriði. Ef neytendur eru stranglega háðir reitnöfnum eða villutextum verður hver uppfærsla dýr. Viðnámshæfni hjá neytanda er því verkefnismarkmið, ekki „Nice-to-have“.

Áætla rollback raunsætt: keyrslueiningar og gögn

Afturför (Rollback) er aðeins raunhæf ef tekið er tillit til gagnaásjónar. Þjónusta má tæknilega afturkalla, en ef ný útgáfa hefur þegar skrifað gögn í nýju formi getur fyrri útgáfan orðið óvinnufær. Því eru „expand/contract“-migrationen (fyrst stækka, síðan skipta yfir, síðan hreinsa upp) oft stöðugri stefna í fyrirtækjarekstri.

Monitoring und Incident-Response: Was vor dem ersten Vorfall stehen sollte

Ein REST-Daemon wird erst durch Beobachtbarkeit (Observability) wirklich betriebssicher. Gemeint ist: Metriken, Logs und – wo sinnvoll – verteilte Ablaufspuren (Tracing) so kombinieren, dass Störungen schnell eingegrenzt werden können.

Basis-Metriken für REST-Services

• Request-Rate: Requests pro Minute, idealerweise pro Endpoint.
• Latenz: p50/p95/p99, um Ausreißer sichtbar zu machen.
• Fehlerquoten: 4xx vs. 5xx, zusätzlich nach Fehlercode differenziert.
• Ressourcen: CPU, RAM, Thread-/Pool-Auslastung, Datenbankpool-Auslastung.

Damit lassen sich typische Ursachen schneller erkennen: Datenbank langsam (Latenz steigt, Pool erschöpft), Client fehlerhaft (4xx steigt), Ressourcenproblem (RAM wächst), Sperrsituationen (Timeouts, Latenzspitzen).

Runbooks: Betriebsfähigkeit ist auch Dokumentation

Gute Services scheitern im Ernstfall oft an fehlenden Betriebsroutinen. Ein Runbook ist eine kurze, praktische Anleitung: Wo sind Logs und Dashboards? Welche Checks sind relevant? Wie wird der Service kontrolliert neu gestartet? Welche Konfigurationen sind typische Fehlerquellen? Das ist besonders wichtig, wenn Betrieb, Fachseite und externe Partner gemeinsam arbeiten.

Modernisierungspfad: Bestandslogik weiterverwenden, aber sauber kapseln

Viele Unternehmen haben Delphi-Bestände, die fachlich wertvoll sind. Ein Linux-REST-Daemon kann ein Modernisierungsschritt sein, ohne sofort die gesamte Client-Landschaft zu ersetzen. Typische Vorgehensweisen:

• Strangler-Pattern: Neue Funktionen gehen zuerst in den Service, alte bleiben im Bestand, bis sie schrittweise ersetzt sind.
• API vor Datenbank: Statt dass mehrere Anwendungen direkt auf dieselbe Datenbank zugreifen, wird Zugriff über den Service kanalisiert. Das verbessert Governance und reduziert Schattenintegrationen.
• Schnittstellen schrittweise ablösen: Datei- oder Direktzugriffe werden parallel zu REST betrieben und dann kontrolliert abgeschaltet.

Wichtig ist dabei eine klare Zielarchitektur: Welche Verantwortlichkeiten bleiben im Bestand, welche wandern in den Service, und wo entstehen neue Abhängigkeiten (z. B. Identity, Proxy, Monitoring)? Ohne diese Klärung wächst sonst ein „Service neben dem Bestand“, der später genauso schwer zu betreiben ist.

Praxis-Checkliste: Was vor dem Go-live geklärt sein sollte

Zum Abschluss eine Checkliste, die sich aus Betriebs- und Integrationssicht bewährt hat:

• API-Vertrag: OpenAPI vorhanden, Fehlercodes definiert, Versionierung und Deprecation geklärt.
• Security: TLS über Reverse Proxy, Auth/SSO integriert, Rollenmodell, Secret-Handling.
• systemd: Restart-Policy, Logging-Integration, eigener Service-User, Rechte minimal.
• Daten: Transaktionsgrenzen sauber, Migrationen versioniert, Backup/Restore getestet.
• Observability: Correlation-ID, Metriken/Dashboards, Alarmierung, Runbook.

Niðurstaða: Velgengni byggist á aga í rekstri og viðmótastjórnun

Velgengni Delphi Linux REST-Daemons fyrir fyrirtæki ræðst sjaldan af því hvort „Delphi keyrir á Linux“ – það er yfirleitt ekki stærsta hindrunin. Ákveðandi eru hreinar samningar um viðmót, stjórnaður gagnaaðgangur, skýr rekstrarmódel með systemd, öryggi í gegnum Reverse Proxy og miðlægar auðkenningar auk eftirlits- og uppfærsluáætlana sem spegla daglegt starf í gagnaveri eða í skýinu.

Ef þú ætlar að byggja upp leið til nútímavæðingar, API-stefnu eða traustan rekstrarramma fyrir Linux-Services, er ráðlegt að móta málið snemma saman – áður en undirskilnar ákvarðanir festast í rekstrinum.

Í faglegu umhverfi gegna einnig Delphi REST-API og REST-Server og systemd-þjónustur mikilvægu hlutverki þegar samþættingar, gagnastreymi og áframhaldandi þróun þurfa að spila snyrtilega saman.

Ræddu verkefni eða nútímavæðingarverkefni við Net-Base.