Jeśli chciałbym wysłać emaila do kogoś wiadomość w mojej aplikacji i mieć pewność że ona ją otrzyma. Bo wysyłająć do kogoś wiadomość asynchorniczną lub jakimś innym ządaniem to jest szana że wiadomość nie dotrze do adresata z różnych powodów(brak sieci).
I teraz taka wiadomość może trafić do mojego serwera, pózniej do bazy danych. No i właśnie, co dalej? jakieś api do takich zadań?
0
1
Nie do końca rozumiem jaki problem chcesz rozwiazać. Możesz np. wrzucać event na jakaś kolejkę i z tej kolejki asynchronicznie zdejmować i wykonywać akcje. Jeśli się nie powiedzie to zwracasz element do kolejki (wiele kolejek ma w ogóle taki ficzer że jak w odpowiednim czasie nie "oznaczysz" pobranego elementu za zakończony, to samoczynnie wróci do kolejki).
0
np. właściwie tak samo jak na fb. Muszę mieć pewnosć że wiadomość tekstowa (czat) została doręczona do adresata.
To też tyczyło by sie emaili. A masz może przkład takiej kolejki bo nie wiem za bardzo o co chodzi.
0
Mechanizm będzie różny w zależności od medium. W mailach jest prosto - ktoś musi kliknąć na link, read receipt nikt nie klika, wiele klientów nie wyświetla też remote content. Po prostu wygeneruj ID dla wiadomości i zamieść link w którym jest mail i ID wiadomości, jeśli link zostanie kliknięty - wiadomość odczytano. Jak masz jakieś czaty które sam piszesz to możesz sobie tam wrzucić dowolny JS, na przykład taki który po 5s focusu oznacza wiadomość jako odczytaną.
0
wiesz co nie chodzi o to żeby mieć pewność czy ktoś przeczytał tylko czy wiadomość dotarła, bo mogła nie dotrzeć przez błąd sieci np.
0
W takim przypadku system który otrzymuje wiadomość powinien ją potwierdzić. Ale tutaj jest pewien problem (problem dwóch generałów) który nam trochę komplikuje sprawę. Jeśli potwierdzenie nie wchodzi w rachubę to cóż - o ile nie dostałeś błędu przy wysłaniu (gdzie na pewno wiadomość nie dotarła, powtórz z jakimś backoffem) albo timeoutu (nie wiadomo co się stało, mogła dojść lub nie) to niewiele jesteś w stanie zrobić. Stąd generalnie
To o czym wspominał Shalom to chociażby mechanizm visibility timeout na SQSie w AWS - ty publikujesz wiadomości na kolejkę, broker potwierdza ci że wiadomość dostał (w przypadku timeoutów możesz skorzystać z czegoś takiego jak deduplication id żeby nie wysłać tej samej wiadomości dwa razy) i tyle cię to obchodzi z perspektywy nadawcy, a cały cyrk z dostarczeniem dzieje się po drugiej stronie kolejki - taki system który ściąga coś z kolejki dostaje pewien okres czasu (visibility timeout) na potwierdzenie jej przetworzenia poprzez usunięcie jej z kolejki - jeśli zwiśnie albo umrze, to wiadomość po upływie visibility timeout będzie widoczna dla innych klientów. Jeśli wystarczająco dużo razy ten visibility timeout upłynie, to albo zostanie wywalona na stałe z systemu, albo wyląduje na dead letter queue (zwykle wtedy wychodzi na to że wiadomość ma zły format).
O mailach się nie wypowiem bo to raczej skomplikowany temat (wiele serwerów SMTP sobie te wiadomości kolejkuje i próbuje ponownie doręczyć) a moja wiedza jest dość pobieżna.
W każdym przypadku powinieneś wziąć pod uwagę efekt nieefektywnego dostarczenia na twoją logikę biznesową - jeśli to jakieś notyfikacje o czymś pierdółkowatym, to najlepiej olać sprawę jeśli 99% wiadomości zostanie dostarczone. Jeśli to jakiś proces typu potwierdzenie zamówienia, powinieneś umożliwić użytkownikowi podglądnięcie aktualnego stanu i zrobienie tego samego co dostaje w notyfikacji bezpośrednio w twoim systemie. Wszystko zależy od konkretnego problemu.
1
Protokoly mailowe wydaja sie byc polaczeniowe (TCP). A zatem serwer zwyczajnie dostaje ACK od serwera odbiorcy, informujace ze wiadomosc dotarla.
Czy o to Ci chodzi?
3
@phanc: Java mail powinien rzucić jakimś wyjątkiem gdyby był błąd (sieci, konfiguracji poczty etc). Robisz to w jakimś wątku na przykład, jeśli poleci błąd, możesz wrzucić jeszcze raz to kolejki na przykład.
0
SMTP zakłada że wiadomość przechodzi przez serię pośredników (relayów), otrzymanie potwierdzenia od pierwszego relaya nie oznacza że wiadomość nie zostanie dropnięta przez system docelowy. Do tego dużo zależy od konfiguracji - jeśli teraz wyślę z mojego gmaila wiadomość na mój świeżo przeorany VPS który odbija połączenia na porcie 25, to dostanę za 3 dni wiadomość że mail nie został dostarczony (bo gmail robi retry).
1
@Zing: Mowisz ze w protokole SMTP nie ma mechanizmu potwierdzania odbioru? ;)
0
SMTP ma potwierdzenie odbioru od serwera do którego się łączysz. Nie wiesz czy serwer do którego się łączysz to relay czy nie.
0
Ale to jest az tak glupie? W takim zwyklym internecie tez masz N routerow po drodze. Nie laczysz sie bezposrednio. A odpowiada Ci host docelowy.
0
W internecie jak używasz TCP to masz warstwę abstrakcji nad IP i innymi ethernetami które na podstawie timerów i liczników po twojej stronie decydują czy przypadkiem połączenie nie zostało zerwane, nie masz takiej warstwy abstrakcji nad SMTP.
0
Tutaj przykład sesji SMTP z gmailem (konto musi mieć wyłączone MFA), trochę wyciąłem opensslowej sieczki:
openssl s_client -crlf -connect smtp.googlemail.com:25 -starttls smtp
250 SMTPUTF8
auth login
334 VXNlcm5hbWU6
<username z @gmail.com w base64>
334 UGFzc3dvcmQ6
<hasełko w base64>
235 2.7.0 Accepted
mail from: <<moj mail="mail">>
250 2.1.0 OK 18sm20540385wmj.21 - gsmtp
rcpt to: <<mail w domenie w której wiem że nie istnieje serwer smtp>>
250 2.1.5 OK 18sm20540385wmj.21 - gsmtp
data
354 Go ahead 18sm20540385wmj.21 - gsmtp
Subject: test
test
.
250 2.0.0 OK 1617568766 18sm20540385wmj.21 - gsmtp
A dostałem od [email protected] odbitkę na maila:
Address not found
Your message wasn't delivered to .... because the domain .... couldn't be found. Check for typos or unnecessary spaces and try again.
The response was:
DNS Error: 4752201 DNS type 'mx' lookup of ..... responded with code NOERROR 4752201 DNS type 'mx' lookup of .... had no relevant answers. 4752201 DNS type 'aaaa' lookup of .... responded with code NOERROR 4752201 DNS type 'aaaa' lookup of ..... had no relevant answers. 4752201 DNS type 'a' lookup of ..... responded with code NOERROR 4752201 DNS type 'a' lookup of ..... had no relevant answers.
A więc operacja przebiegła pomyślnie, pacjent zmarł.