I notice that if I pull the plug on my connection (turn off WiFi), MailSocket.IsConnected remains True. I have a button on a Dialog that checks MailSocket1.IsConnected to test this out. MailSocket1 is an SMTPSecureSocket that is called by the SendMail method. So it seems that once the connection is made, killing the connection manually fails to result in MailSocket1.IsConnecting being False.
However, if I pull the plug before invoking the SendMail method, this appropriately results in an Error 103.
What might I be missing in the first paragraph above.
Should it make a difference, MailSocket1 is a Session Property that’s set this way in Session.Open:
Dim s As New MailSocket
s.Session = App.SessionWithIdentifier(Self.Identifier)
Self.MailSocket1 = s
TCP sockets of all kinds are quite passive. You don’t find out that such an error has occurred until you try to do something else with it (like in your other statement where if you pull it before you send you get an error).
Interesting. Good info, Jason. Is there a way for me to ping the mail server to test the connection. I wonder if I can use its Poll method. In the end, my test was kind of useless because, now that I think of it, if I kill the connection, the app is kind of useless anyway in this situation because it’s a Web app!
The only way, that I know of, to tell if you are connected is to try & do something. For a mail sending socket that is try to send a mail or try & get the list of unread mails - something that requires some back and forth between the client & server.
However, I find that following Timer works as long as I don’t manually kill the connection midstream, by closing WiFi:
[code]// If connected turn on ProgressWheel.
If Session.MailSocket1.IsConnected Then
Self.ProgressWheel1.Visible = True
End If
// If no longer connected turn ProgressWheel off.
If Not Session.MailSocket1.IsConnected And _
Session.MailSocket1.BytesLeftToSend = 0 Then
Self.ProgressWheel1.Visible = False
Me.Mode = Timer.ModeOff
If Session.MailSocket1.LastErrorCode = 0 Or _
Session.MailSocket1.LastErrorCode = 102 Then
MsgBox “Agent emails sent.”
End If
Return
End If
// If not connected but there are some bytes left, an Error.
If Not Session.MailSocket1.IsConnected And _
Session.MailSocket1.BytesLeftToSend > 0 Then
Self.ProgressWheel1.Visible = False
Me.Mode = Timer.ModeOff
MsgBox “Server error.”
Return
End If[/code]
The above Timer code seems to accurately reflect whether or not a connection exists. I can test it with a button that checks
MailSocket1.IsConnected
I press the above button a few times while seeing the ProgressWheel spinning, and I’m told I’m connected. When the ProgressWheel dies, any press of that button tells me I’m not connected. This logic seems to work fine unless I manually terminate the connection. But I’m now assuming this might be because this is a Web app, so things are screwy because the overall connection is gone, not just the mail server connection.
Please do not use BytesLeftToSend on mail sockets.
They send several requests, so the only trigger to know they are done is setting something in Mailsent event.
[quote=386128:@Christian Schmitz]Please do not use BytesLeftToSend on mail sockets.
They send several requests, so the only trigger to know they are done is setting something in Mailsent event.[/quote]
In the past, I have found that MailSent sometimes doesn’t fire. Can’t I assume that if the connection is terminated and there are no bytes left to send, that all mail was sent?
That’s a good idea. Now my timer object checks to see if MailSocket1.MailSent updated Boolean property Session.Email_MailSent as True, or MailSocket1.MessageSent eventually incremented property Session.Email_MessagesSent to a number that matches the expected number. If either is the case, the ProgressWheel is turned off and the timer is shutdown.
You only get the disconnect error if the remote host calls the shutdown method on the socket properly. If the connection just dies for some physical or other reason then you get no error until you try to send something down it. There are IMAP ping methods, perhaps we should ask that an SMTP ping be implemented. It could be as simple as re-sending the HELO message once in a while to make sure that the connection is still valid. If it doesnt get a response then the connection was killed without properly sending the shutdown command.
Well you can always Disconnect() and then reconnect, and wait for the ConnectionEstablished(Greeting As String) event.
Do that before you create and send your emails and perhaps when there are no mails to check. It gives you a heartbeat way as close as it can be.