Mail nach XXX Sekunden verschicken

[virtus]

Mail ist langsam, für Echtzeit-Anwendungen gänzlich unbrauchbar. Bei komplexen Mailsystemen mit hohem Mailaufkommen und komplexen Regeln, wie sie im Unternehmensumfeld vorkommen, kann der Mailversand mehrere Stunden oder sogar Tage in Anspruch nehmen. Insbesondere, wenn es der Spamvermeidung gilt, werden Nachrichtenübertragungen gerne mal um z.B. 24h verzögert. Da es wie die anderen schon gesagt haben, aber wohl sowieso nicht tatsächlich Echtzeit sein muss, wäre das eventuell noch zu verschmerzen. Trotzdem würde ich von Mails abraten, auch deshalb, weil die Weiterverarbeitung erschwert wird und weil eine in diesem Fall unnötige dritte Komponente ins Spiel gebracht wird.
SMS sind nicht mehr state of the art wenn es um Echtzeit-Nachrichten gehen soll. Zumal auch hier Verzögerungen nicht unüblich sind. Abgesehen davon sprechen die finanziellen Kosten für dich als Anbieter und die ideellen Kosten für den Nutzer (Preisgabe der Mobilfunknummer, Vertrauen in eine fremde Person und die Sicherheit ihrer Infrastruktur) gegen SMS.
PHP ist nicht die passende Sprache für dein Anliegen. Natürlich wäre es auch damit machbar, es gibt allerdings Sprachen, die sich dazu deutlich besser eignen.
SQL-Datenbanken kannst du verwenden, in dem Fall würde ich allerdings eher davon abraten.

An deiner Stelle würde ich einen kleinen Socketserver aufsetzen, der Clients, Termine und Nachrichten verwaltet.
Prinzipiell:
Du öffnest zwei Kanäle, einen Kontrollkanal und einen Nachrichtenkanal.
Zum Kontrollkanal verbindest du dich bzw. deine Anwendung verbindet sich zu diesem Kanal. Hierüber kannst du Nachrichten einspeisen.
Der zweite Kanal, der Nachrichtenkanal dient den Clients als Verbindungspunkt. Diese können sich wahlweise über eine Webseite oder über eine App verbinden. Hierüber kannst du Clients eine Nachricht übermitteln, sobald eine eingespeiste Nachricht ihre Fälligkeit erreicht.
Insgesamt sollte das deutlich leichtgewichtiger als ein Webserver mit PHP, ein Datenbankserver und ein Mailserver sein. Vermutlich ist es schon leichtgewichtiger, als jeder der voraus genannten Server alleine für sich.

Der Vorteil wäre eben, dass die Gegenseite quasi frei definiert werden kann. Hier kann ein Websocket auf Basis von JavaScript geöffnet werden oder eine App kann die Socketverbindung aufbauen.

Die Implementierung dürfte, je nach Anforderungen nicht sonderlich kompliziert werden.

Sofern unproblematisch, könntest du die Nachrichten auch direkt an den Client übermitteln und dort quasi bei Fälligkeit "aufpoppen" lassen. Dann musst du sie nicht auf dem Server zwischenspeichern und du musst dich nicht um das Timing kümmern. Das wäre, behält man 100mio Clients im Hinterkopf, deutlich weniger Belastung für dich/ deinen Server.

 

[alter_Bekannter]

You do not have permission to view link please Anmelden or Registrieren

Wenig überraschend, ich kenne die Datenbank Performance eines kleinen online TCG's. Selbst das Abfragen aller Karten eines Spieler hat deutlich weniger als eine Sekunde gedauert. Und die Tabelle hat auch ein paar Millionen Einträge und man will in dem fall dann so im Schnitt so ~2000 Ergebnisse.

@virtus
Worauf basierst du diese Sicherheit das 50 Millionen offene Verbindungen weniger problematisch sind?

Gameserver benutzen üblicherweise UDP unter anderem um nicht so viele Verbindungen handeln zu müssen. Gerade weil solche Idlesachen auch nicht kostenlos zu handlen sind nutzt man schon seit Ewigkeiten Pseudokonversationskonzepte. Denn da kann man gerade bei nicht Echtzeitkritischen Sachen echt viel sparen.

 

[virtus]

@virtus
Worauf basierst du diese Sicherheit das 50 Millionen offene Verbindungen weniger problematisch sind?

Bei einem kleinen Socketserver kann man diesen recht einfach duplizieren und Nutzer verschiedener Regionen verschiedenen Instanzen des Servers zuzuweisen.
Bei der Datenbanklösung müsstest du mehrere Datenbankserver permanent untereinander synchronisieren - zumal zum Synchronisieren permanent neue Einträge in die Datenbank eingespeist werden müssen und permanent abgelaufene Einträge gelöscht werden und vorhandene Einträge abgefragt werden - und selbst dann entfällt kein zweiter Dienst der die Einträge aus der Datenbank verarbeitet, also die Nutzer selbst kontaktiert.

Gameserver benutzen üblicherweise UDP unter anderem um nicht so viele Verbindungen handeln zu müssen. Gerade weil solche Idlesachen auch nicht kostenlos zu handlen sind nutzt man schon seit Ewigkeiten Pseudokonversationskonzepte. Denn da kann man gerade bei nicht Echtzeitkritischen Sachen echt viel sparen.

Die Herausforderung entfällt nicht bei deine👎 Lösungen. Vielleicht sollte aber auch mal geklärt werden, wie sehr/ wenig "Echtzeit" wirklich benötigt wird. Ggf. ist eine Mail tatsächlich ausreichend.
Bei Spielen wird dazu allerdings häufig auch ein lokaler Server eingerichtet und es werden Portfreigaben benötigt. Das ist im Mobilfunknetz afaik nicht möglich, da du hinter einer Provider-NAT/ Proxy sitzt.
Wenn du keine Verbindung dauerhaft offen halten willst, muss der Client regelmäßig nachfragen, ob neue Nachrichten vorhanden sind. Ob du das nun über eine TCP Verbindung, die geöffnet und wieder geschlossen wird oder über UDP regelst, bleibt dir überlassen.
Solange die 50k Marke nicht erreicht ist und noch im kleinen Maßstab Suppe gekocht wird, würde ich eine Verbindung offen halten, damit bist du zumindest näher an Echtzeit..

Falls dir noch andere brauchbare Konzepte bekannt sind, wäre ich natürlich interessiert.

 

[alter_Bekannter]

Mail würde ich hier echt nicht mehr nutzen, aber nur weils unnötig kompliziert ist. Und damit meine ich nicht nur den technischen sondern viel mehr den organisatorischen Overhead, Spamfilter/Blacklists von anderen zum Beispiel.

Wenn man eh dauerhaft eigenen Code auf dem Client am laufen hat macht das Mailprotokoll alles nur komplizierter ohne irgendwelche Vorteile.

Ob eine Dauerverbindung brentiert hängt natürlich von der Frequenz ab in der Nachrichten verschickt werden. Aber so wie ich das verstanden habe sind die Nachrichten für eine Auswertung durch Menschen geplant und da wirds auf über 99% Idle hinauslaufen.