Socket problem

I have a very simple little program that connects to our email server to
send out emails. When I compiled it with .VS2003 (net 1.1), it works fine.
with VS2005 (.net 2.0), it hangs on the last ReadInfo

Any suggestions? thanks!

Public Function send2() As String
Dim err As String = ""

soc = ConnectSocket(Server, 25)
Debug.Write(ReadInfo(err) & vbCrLf)
WriteInfo("HELO", Err)
Debug.Write(ReadInfo(err) & vbCrLf)

WriteInfo("MAIL FROM:" & From, err)
Debug.Write(ReadInfo(err) & vbCrLf)

WriteInfo("RCPT TO:" & "RTorcellini@mydomain.com", err)
Debug.Write(ReadInfo(err) & vbCrLf)

WriteInfo("DATA", err)
Debug.Write(ReadInfo(err) & vbCrLf)

WriteInfo("This is a test" & vbCrLf & "." & vbCrLf, err)
Debug.Write(ReadInfo(err) & vbCrLf)

WriteInfo("QUIT", err)
Debug.Write(ReadInfo(err) & vbCrLf) 'CODE HANGS HERE- SEE BELOW
soc.Close()
End Function

Private Function WriteInfo(ByVal Info As String, ByRef err As String) As
String
Dim bytes As Byte()
Dim ASCII As Encoding = Encoding.ASCII
bytes = ASCII.GetBytes(Info & vbCrLf)
soc.Send(bytes, bytes.Length, 0)
End Function

Private Function ReadInfo(ByRef Err As String) As String
Try
Dim bytes As Int32
Dim RecvBytes(256) As Byte
Dim ASCII As Encoding = Encoding.ASCII
bytes = soc.Receive(RecvBytes, RecvBytes.Length, 0) 'HANGS HERE
ON LAST ReadInfo
Return ASCII.GetString(RecvBytes, 0, bytes)
Catch ex As Exception
Err = ex.Message
End Try
End Function

Peter
Thu Mar 22 12:02:16 CDT 2007

On Thu, 22 Mar 2007 09:15:10 -0700, Rob T
<RTorcellini@DONTwalchemSPAM.com> wrote:

> I have a very simple little program that connects to our email server to
> send out emails. When I compiled it with .VS2003 (net 1.1), it works
> fine.
> with VS2005 (.net 2.0), it hangs on the last ReadInfo

Your code displays the classic beginner bug of assuming that a single
receive will actually receive every byte that was sent. That's not true.
The Receive method can return anywhere between 1 and the total numebr of
bytes sent. It is your responsibility to keep receiving bytes until
you've gotten as many as you expect or need.

I would be surprised if changing the compiler is actually what changed the
behavior...but regardless, I suspect that if you fix the code so that in
ReadInfo, you loop until you've read as many bytes as you really want, it
will work fine. In the specific example, it appears that you want to
receive until you've gotten the cr/lf terminator for each line of data.
For different situations, you will use different criteria.

Pete

Rob
Fri Mar 23 09:26:19 CDT 2007

As a followup to this. There is nothing wrong with the code. Our IT dept
had deployed a new version of Symantec Antivirus and it had the SMTP client
installed....blocks just about everything! Once I disabled it....let the
good times roll!


"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
news:op.tpln92hu8jd0ej@petes-computer.local...
> On Thu, 22 Mar 2007 09:15:10 -0700, Rob T
> <RTorcellini@DONTwalchemSPAM.com> wrote:
>
>> I have a very simple little program that connects to our email server to
>> send out emails. When I compiled it with .VS2003 (net 1.1), it works
>> fine.
>> with VS2005 (.net 2.0), it hangs on the last ReadInfo
>
> Your code displays the classic beginner bug of assuming that a single
> receive will actually receive every byte that was sent. That's not true.
> The Receive method can return anywhere between 1 and the total numebr of
> bytes sent. It is your responsibility to keep receiving bytes until
> you've gotten as many as you expect or need.
>
> I would be surprised if changing the compiler is actually what changed the
> behavior...but regardless, I suspect that if you fix the code so that in
> ReadInfo, you loop until you've read as many bytes as you really want, it
> will work fine. In the specific example, it appears that you want to
> receive until you've gotten the cr/lf terminator for each line of data.
> For different situations, you will use different criteria.
>
> Pete

Peter
Fri Mar 23 09:37:00 CDT 2007

On Fri, 23 Mar 2007 07:26:19 -0700, Rob T
<RTorcellini@DONTwalchemSPAM.com> wrote:

> As a followup to this. There is nothing wrong with the code.

Well, your code still has the bug I describe. So it's not actually true
that "there is nothing wrong with the code". It may work fine now, but it
is likely to break some time in the future.