Lazarus és Delphi programok közötti "beszélgetés"
2022-08-04T21:25:59+02:00
2022-08-09T03:29:59+02:00
2022-08-09T03:45:25+02:00
  • Az adatmennyiség miatt nem aggódnék! Mint azt topik nyitásakor is írtam:

    - Max 2-4 programot kell csak lokálisan összeszinkronizálni.
    ... ha pedig ehhez hozzávesszük, hogy:
    - Max 300 rendelést tud egyszerre kezelni egy étterem. (Reggeli menüztetés/ételkihordás...)
    - Egy rendelés max 200 bájt adat (Azonosító + cím + futárnév + GPS)
    - A webszerver mindegy, hogy 50 vagy 5000 futárt "követ" országosan, hiszen:
    - egy futár-GPS csak kb 64 bájt azonosítóval együtt.
    - és egy étterem csak annak az 1-10 futár koordinátáját kaphatja meg, akik náluk dolgoznak!

    Sőt, még ha hozzárakunk timestamp-eket, user/pass-t, biztonsági CRC-t, stb. akkor sem éri el mindez összesen a 100 KB-ot.
    Tehát memória alapon bőőőőven lehet mindezt kezelni.
    Mutasd a teljes hozzászólást!
  • Köszönöm a hosszú választ!

    Adatbázis kapcsolatot erre továbbra sem találom jó megoldásnak. Felesleges.
    Emellett túlzottan érzékeny a hálózatra. Nagyon rosszak a tapasztalataim ilyen téren.

    Tudom hogy működik a "riasztás", jelenleg FirebirdSQL-t használok Delphi 7 alatt, ott is vannak EVENT-ek, amik többnyire megbízhatóak, ha jól van konfigurálva a tűzval. De Wifin, túlmelegedő switcheknél, stb. katasztrofális, felejtős.

    Tehát messze elmarad az a technológia a mai modern lehetőségekhez képest, ahol a "eseménnyel" egyidőben az adat is megérkezhet úgy akár TÖBB másik programhoz egyszerre, hogy nem kell újabb kapcsolatot kiépíteni. A socket + *MQ* egy fantasztikus találmány, szeretném kihasználni egy kész library formájában.

    Ma például találtam olyat, hogy: RabbitMQ. Van delphi és lazarus alá is, bár ez utóbbi fizetős: 80.000.- Ft.

    Illetve van még:
    GitHub - grijjy/DelphiZeroMQ: Delphi implementation of ZeroMQ Majordomo protocol and CZMQ high level
    ... és hasonlók.

    Tehát van választék, de emiatt egyben az is gond:
     - melyik mennyire stabil és
     - mennyibe kerül.
    Mutasd a teljes hozzászólást!
  • "Az adatoknak csak a fele lenne elérhető az adatbázisból. A térkép program még máshonnan is gyűjt/lekér majd."

    Nem tudom, pontosan mennyi adatról van szó és milyen gépeken kell feldolgoznod, de ez nekem úgy tűnik, mintha kellene egy service, ami gyűjti/lekéri az adatokat és beszúrja/frissíti egy (akár in-memory) adatbázisba, a többi service-ed pedig innen kérné le. MongoDB például tud notifikációt is küldeni a csatlakoztatott klienseknek adatváltozás esetén, azt nem tudom, hogy ezt Lazarus alatt mennyire könnyű használni.

    "A pizza-programba épített webszerver lenne a legegyszerűbb megoldás, de azzal nem lenne kezelhető szerintem olyan fajta azonnali interaktivitás, mint amit szeretnék."

    Ha rendesen leválasztod, nem lesz nehéz később cserélni alacsonyabb szintűre, de nem hiszem, hogy olyan adatforgalmat produkálnál, amire egy HTTP REST API és egy Websocket kombó ne nyújtana megoldást LAN-on.

    "Mivel a Lazarus-os térkép programba egyébként is be kell építenem az MQTT-t, ezért jelenleg ez a leginkább befutó."

    Az MQTT is jó protokoll, de nem tudom, hogy Delphi 7 alá mit fogsz találni. Visszautalva az első pontra, az MQTT-s részt kiszervezném külön service-be, ami pl. egy adatbázisba tol mindent.

    Egyébként milyen adatmennyiségről és milyen frissítési gyakoriságról beszélünk? Nem mindegy, hogy 30 vagy 3000 futár van pl. :)
    Mutasd a teljes hozzászólást!
  • ... kiegészítés:
    Találtam tegnap egy másik megoldást:
    ZeroMQ

    de végül elvetettem, mert a delphis kód nem támogatja a legfrissebb változatot, az FPC kódot kellene átírni D7 alá is,
    továbbá nincs túl jól dokumentálva a pascalos GIT.
    Mutasd a teljes hozzászólást!
  • Köszönöm az eddigi tippeket!

    1. Nem, nem adatbázist akarok szinkronizálni. Az adatoknak csak a fele lenne elérhető az adatbázisból. A térkép program még máshonnan is gyűjt/lekér majd. (Futárok pozíciója, MQTT VPS-ről.)

    2. A pizza-programba épített webszerver lenne a legegyszerűbb megoldás, de azzal nem lenne kezelhető szerintem olyan fajta azonnali interaktivitás, mint amit szeretnék. Ráadásul az külön szálakon fut, jó elszigetelve a Fő-alkalmazástól, főként csak adatbázis műveleteket és néhány szálbiztos változót használva.

    3. Igen, nekem valamilyen "socket"-es megoldásra lenne szükségem, tehát a feladat inkább úgy specifikálódott bennem mostanra:
     - milyen library lenne stabil

    4. Mivel a Lazarus-os térkép programba egyébként is be kell építenem az MQTT-t, ezért jelenleg ez a leginkább befutó. Már csak azt kellene tudni eldönteni, van-e egyáltalán olyan forráskód, ami stabil mind Delphi 7 és mind Lazarus alatt?

    Ez a legfrissebb topik a kérdéskörben. Sajnos ez sem natív kód, csak egy Header API, de legrosszabb esetben megoldom a DLL deploy-t.
    Illetve még a Mosquito telepítés is felmerül ebben az esetben. Nem örülök, de ez a kisebbik rossz, mert ezzel feloldom a many-to-many problémát egy brókerrel.

    Így lényegében bármennyi PizzaProgram bármennyi térkép-appal együtt tud majd működni a hálózaton.

    Ami esetleg még aggaszt, hogy mennyire szálbiztos a Mosquito kliens? Mi történik, ha egyszerre két szerverre iratkozik fel?
    Mutasd a teljes hozzászólást!
  • Webszerver, ha a HTTP lassú, akkor Websocket-tel. Az az előnye a TCP-hez képest, hogy:
    - Nem neked kell a protokollt kitalálnodés ledokumentálnod. (TCP-n neked kell megtervezned a csomagokat, UDP-nél meg mindent is. :) )
    - Vannak hozzá third-party eszközök, könnyen tudod debuggolni és monitorozni
    - ha később bele kell ültetni valami nagyobb (akár felhős) infrastruktúrába, akkor könnyebb dolgod lesz. (Akár titkosítani, hitelesíteni vagy routolni szeretnéd a kéréseket.)

    TCP-t csak akkor használnék, ha valami alacsonyszintű hardverrel kellene beszélgetnem, aminek megvan a saját, TCP-re épülő protokollja, UDP-t pedig akkor, ha realtime, nagy mennyiségű adatátvitel (pl.: videostream) kell, vagy egy tunnel.

    Szerk: mégegyszer elolvasva a hsz-edet, nem arról van szó, hogy kellene egy közös adatbázis amiből/amibe mindenki dolgozhat, ehelyett most próbálod összeszinkronizálni a három példányt, egyfajta "osztott, redundáns adatbázist" készítve ezzel?
    Mutasd a teljes hozzászólást!
  • A webszerver nem rossz megoldás.

    Picivel gyorsabb lehet, ha csak TCP szervert csinálsz.

    Valamivel még gyorsabb az UDP, de ott nem garantált az üzenet célba érése.

    Illetve vannak más hálózati protokollok is, de manapság a fenti kettő az elterjedt.
    Mutasd a teljes hozzászólást!
  • Szakmai javaslatot kérnék arra, mi lenne ideális módja annak, hogy 1 Lazarus program kommunikáljon +2 Delphis EXE-vel?
    Tervezek írni egy "cím + futár térképen megjelenítő" applikációt Lazarus alatt, ami együtt kellene működjön akár több másikkal.

    Egy étteremben előfordul, hogy több példányban futtatják a pizza-programot, mert több néven szállítanak ugyanazzal a futár-gárdával.
    (Azonos a konyhájuk, pl. van egy "magyaros" és a "pizzéria"). Tehát egy térképen, egyben kell lássák a két program összes címét dinamikusan.
    Ha pedig kiválasztanak egy rendelést az egyik pizza-programban, az a térképen is kiválasztódik.

    Persze "visszirányban" is kell tudnia működni, tehát például kijelölnek 5 "cím-GPS-pöttyöt" a Lazarus-os térkép programon, amire a 2+3 cím a két külön programban ki kellene választódjon.

    A jelenlegi gyakorlatom kimerül abban, hogy "építsünk bele egy Indy webszervert" a Delphi programba. De ez nem lenne elég gyors/dinamikus az oda-vissza kommunikációhoz.
    Főként localhost-on kellene működjön oda-vissza irányban, de el tudok képzelni olyat is, hogy egy külső eszközre "csak nézegető" módban ki kellene tenni egy másodlagos térképet, tehát LAN-on is kellene működjön egy irányba.

    Előre is köszönöm a válaszokat!
    Mutasd a teljes hozzászólást!
abcd