UDP Broadcast in Visual Basic?

[gregory_may]

First two links about UDP:

Microsoft Overview of UDP
http://msdn.microsoft.com/library/d.../en-us/cpguide/html/cpconusingudpservices.asp

C# TCP/UDP Client/Server Example
http://www.dotnet247.com/247reference/a.aspx?u=http://www.csharphelp.com/archives/archive134.html

VB Broadcast Class
http://www.knowdotnet.com/articles/udpbroadcastmessage.html

I am trying to create an UDP broadcast to a series of computers (In vb.net).
I would like to allow a new computer to also listen to the broadcast. How
can I synchronize the new machine to the UDP stream?

On a related topic, how can I to recover from a UDP Broadcast dropping
packets?

I think the above source code is a good starting point but don't know how to
UDP works well enough to know how to do the client side error handling. If
I can just know that I didn't get a complete message, that would be a great
start.

So, How do I synchronize & detect errors in a UDP Client? Any one have some
thoughts here? Is it already built in?

Thanks!

 

[Chad Z. Hower aka Kudzu]

I am trying to create an UDP broadcast to a series of computers (In
vb.net). I would like to allow a new computer to also listen to the

You should also consider using Indy. Its free and implements UDP as well as
broadcasting.

http://www.indyproject.org/

broadcast. How can I synchronize the new machine to the UDP stream?

What do you mean by synchronize?

On a related topic, how can I to recover from a UDP Broadcast dropping
packets?

You have to build this in using ack/nack or interpolation.

handling. If I can just know that I didn't get a complete message, that
would be a great start.

Build in packet numbers.

So, How do I synchronize & detect errors in a UDP Client? Any one have
some thoughts here? Is it already built in?

No, its not built in.

 

[Peter Huang]

Hi Gregory,

Thanks for posting in the community.

Could you tell me what you mean by "synchronize" in your post?
Do you mean receiving the UDP packet in sequence since UDP is an
connectless, orderless and un-reliable protocal?

If so, why do you just need to synchronize the new added machine?

Anyway, if you need to guarantee the sequence of the UDP packets, I think
you may need to add a numer which used to identify the Packet in the UDP
stream.
e.g.
You can add an 8 bit at the beginning of the UDP packet to indicate the
sequence number.
And you may need to design your own algorithm to handle the UDP stream. In
the client , you need to detect the sequence number to know if this is the
first UDP packet you need to receive.

Also if you want to recover the dropped UDP packet, you need to sent
request to the server and ask it to resent the current packet.

If you have any concern on this issue,please post here.


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[gregory_may]

Thanks Indy looks cool!!

Ack/nack & Packet numbers is what I was after. Is this built into Indy? I
will have to download it a bit later.

 

[Chad Z. Hower aka Kudzu]

Thanks Indy looks cool!!

It is.

Ack/nack & Packet numbers is what I was after. Is this built into Indy?
will have to download it a bit later.

Its not built in. I have plans to make a demo for the Indy Book, but havent
gotten around to it yet.

 

[gregory_may]

Well, I cant figure out how to make INDY work. The examples are all in
Delphi??? The other examples dont really give me any hints at how to do
UDP.

So, I am back to .net I am trying to broadcast and hit this error. It
seems to only happen when I try to send out anything larger than 64K. Any
ideas how to fix this wimpy .NET UDP 64K barier?:

"System.Net.Sockets.SocketException: A message sent on a datagram socket was
larger than the internal message buffer or some other network limit, or the
buffer used to receive a datagram into was smaller than the datagram itself

at System.Net.Sockets.Socket.SendTo(Byte[] buffer, Int32 offset, Int32 size,
SocketFlags socketFlags, EndPoint remoteEP)

at System.Net.Sockets.UdpClient.Send(Byte[] dgram, Int32 bytes, IPEndPoint
endPoint)

 

[Peter Huang]

Hi Gergory,

I think a UDP packet has the maximum size of a UDP datagram is 65507
bytes.(about 64 kb)

Theoretically, the maximum size of an IP datagram is 65535 bytes, imposed
by the 16-bit total length field in the IP header.(See the figure below)

A summary of the contents of the internet header follows:


0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example Internet Datagram Header


With an IP header of 20 bytes and a UDP header of 8 bytes, this leaves a
maximum of 65507 bytes of user data in a UDP datagram.

I can reproduce the problem with the code below.

Dim udpClient As New UdpClient
'a.txt is larger than 64kb, we can get the same exception as yours.
Dim sr As StreamReader = New StreamReader("c:\a.txt")
Dim line As String
line = sr.ReadToEnd()
Dim sendBytes As [Byte]() = Encoding.ASCII.GetBytes(line)
Try
udpClient.Send(sendBytes, sendBytes.Length, "www.contoso.com",
11000)
Catch ex As Exception
Console.WriteLine(ex.ToString())
End Try

For a workaround, I think you may need to split the string you wants to
send less than 64kb.

Please apply my suggestion and let me know if this help you.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[gregory_may]

So, your saying that its not working only because its physically impossible,
Yea .... I have heard that excuse before.



I will give your suggestion a try, it sounds like it should work. But now I
really need the header numbering in place because UDP can swap ordering on
me. This could take a bit of extra coding.

Thanks!

 

[Chad Z. Hower aka Kudzu]

Well, I cant figure out how to make INDY work. The examples are all in
Delphi??? The other examples dont really give me any hints at how to do
UDP.

Many of the examples are in Delphi yes. But such code is easy to read,
espeically small snippets. No differnet than VB users reading C# or C# users
reading VB.

Also if you look at the UDP classes, most of the methods are pretty self
evident.

So, I am back to .net I am trying to broadcast and hit this error. It
seems to only happen when I try to send out anything larger than 64K.
Any ideas how to fix this wimpy .NET UDP 64K barier?:

Its not a .net issue. You cant send that big in UDP. In fact you should limit
them to 1k.

"System.Net.Sockets.SocketException: A message sent on a datagram socket
was larger than the internal message buffer or some other network limit,
or the buffer used to receive a datagram into was smaller than the
datagram itself

Yes, exactly.

 

[Chad Z. Hower aka Kudzu]

Well, I cant figure out how to make INDY work. The examples are all in
Delphi??? The other examples dont really give me any hints at how to do
UDP.

BTW - while not UDP yet, there are several C# and VB samples here:
http://www.atozed.com/indy/

 

[Peter Huang]

Hi Gregory,

As I said in my first reply, you may need to spare a fix length bytes at
the beginning of the byte array which you wants to send, the fix bytes will
be use to store the sequence number, so that when you receive the UDP
packet ,you will know order.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.