Hi,

I am doing a streaming application from Ipaq to Ipaq. I'm transmiting the
data over a Datagram Socket. One thread is dedicated to sending the data. It
is something alike this :

socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram,
ProtocolType.Udp);

//set a large send buffer to the socket (400 ko)
socket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReceiveBuffer, 400000);

while (keepAlive)
{
byte[] data = dataSource.getData();

socket.SendTo(data , 0, dataSize, SocketFlags.None, remoteEndPoint);

//If I add this line, it is working fine
//Thread.Sleep(50);
}

The dataSize is 38000 bytes. The while loop is executed about 30 times a
second, so it represents a bitrate of around 10 Mbit/S ! which is much more
than my wireless lan network capacity.

The program behavior is the following :
The receiver program start receiving packets... and after about 10 packets,
it is receiving nothing.
The sender program (described above) reports it is sending packets without
interruption even though the receiver is receiving nothing.... after 1 minute
or so, the sender crash "assembly not found exeception", and a soft restart
of the Ipaq is the only way to get it working smooth again.

If I uncomment the line :
Thread.Sleep(50);
the sender works without crashing, and the receiver keeps receiving all the
packets.

It seems that the Socket is not working properly when it is asked to
transmit more data than what it is physically possible to transmit.
I expected the socket.SendTo method to block until the data are actually
sent, so that it would block long enough to slow down the program to the
speed matching the maximum bitrate that can be supported by the network...
but it seems it is not the case. (by the way, I checked the socket has
blocking = true).

I can't let the Sleep operation.. because the data I am sending are real
time, and should be sent as fast as possible..

My questions are :

what's wrong with the socket ?
why doesn't it block longer, to send the data at an appropriate rate?
what can I do to my program to be sure it will not crash, and to send the
data as fast as possible.

Thanks a lot!

Lionel Reyero

I'd say that there's not a single thing wrong with the socket. You're
asking it to send some data and, if the channel is busy, it's buffering it.
When the buffer is full (because you're trying to send faster than the
network bandwidth will allow), it tosses the packets. That's exactly the
way I'd expect it to work. I bet that if you change the buffering, the
amount of data actually delivered will probably change right along with the
buffer settings. You should be looking at the return value from SendTo() to
verify that it's actually sending the bytes that you are providing. When it
doesn't, you need to decide what to do about it...

Paul T.

"Lionel Reyero" <(E-Mail Removed)> wrote in message
news:2E1306F5-64FB-4D8C-B6E9-(E-Mail Removed)...
> Hi,
>
> I am doing a streaming application from Ipaq to Ipaq. I'm transmiting the
> data over a Datagram Socket. One thread is dedicated to sending the data.
> It
> is something alike this :
>
> socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram,
> ProtocolType.Udp);
>
> //set a large send buffer to the socket (400 ko)
> socket.SetSocketOption(SocketOptionLevel.Socket,
> SocketOptionName.ReceiveBuffer, 400000);
>
> while (keepAlive)
> {
> byte[] data = dataSource.getData();
>
> socket.SendTo(data , 0, dataSize, SocketFlags.None, remoteEndPoint);
>
> //If I add this line, it is working fine
> //Thread.Sleep(50);
> }
>
> The dataSize is 38000 bytes. The while loop is executed about 30 times a
> second, so it represents a bitrate of around 10 Mbit/S ! which is much
> more
> than my wireless lan network capacity.
>
> The program behavior is the following :
> The receiver program start receiving packets... and after about 10
> packets,
> it is receiving nothing.
> The sender program (described above) reports it is sending packets without
> interruption even though the receiver is receiving nothing.... after 1
> minute
> or so, the sender crash "assembly not found exeception", and a soft
> restart
> of the Ipaq is the only way to get it working smooth again.
>
> If I uncomment the line :
> Thread.Sleep(50);
> the sender works without crashing, and the receiver keeps receiving all
> the
> packets.
>
> It seems that the Socket is not working properly when it is asked to
> transmit more data than what it is physically possible to transmit.
> I expected the socket.SendTo method to block until the data are actually
> sent, so that it would block long enough to slow down the program to the
> speed matching the maximum bitrate that can be supported by the network...
> but it seems it is not the case. (by the way, I checked the socket has
> blocking = true).
>
> I can't let the Sleep operation.. because the data I am sending are real
> time, and should be sent as fast as possible..
>
> My questions are :
>
> what's wrong with the socket ?
> why doesn't it block longer, to send the data at an appropriate rate?
> what can I do to my program to be sure it will not crash, and to send the
> data as fast as possible.
>
> Thanks a lot!
>
> Lionel Reyero

Thanks Paul, I will check that return value.
In case it says that the data has not been sent, I think I will make the
thread sleep for a while. But when it wake up, I would need to check if the
old data has been sent... should I invoke the SendTo() method again ,with the
same data ?
The best would be to invoke a method to check the amount of data in the
SendBuffer. Is this possible ? (can the IOControl() method do that?)

Thanks in advance,

Lionel

"Paul G. Tobey [eMVP]" wrote:

> I'd say that there's not a single thing wrong with the socket. You're
> asking it to send some data and, if the channel is busy, it's buffering it.
> When the buffer is full (because you're trying to send faster than the
> network bandwidth will allow), it tosses the packets. That's exactly the
> way I'd expect it to work. I bet that if you change the buffering, the
> amount of data actually delivered will probably change right along with the
> buffer settings. You should be looking at the return value from SendTo() to
> verify that it's actually sending the bytes that you are providing. When it
> doesn't, you need to decide what to do about it...
>
> Paul T.
>

My guess is that, if it's not sent, you have to send it again. UDP handles
things at the packet level so I think that what it's telling you is that it
didn't have room for the packet, so. I'd say that the right way to do it is
to just resend the data if it fails. Are you sure that you don't want to
use TCP?

Paul T.

"Lionel Reyero" <(E-Mail Removed)> wrote in message
news:A43BF94B-C1B8-43F1-A588-(E-Mail Removed)...
> Thanks Paul, I will check that return value.
> In case it says that the data has not been sent, I think I will make the
> thread sleep for a while. But when it wake up, I would need to check if
> the
> old data has been sent... should I invoke the SendTo() method again ,with
> the
> same data ?
> The best would be to invoke a method to check the amount of data in the
> SendBuffer. Is this possible ? (can the IOControl() method do that?)
>
> Thanks in advance,
>
> Lionel
>
> "Paul G. Tobey [eMVP]" wrote:
>
>> I'd say that there's not a single thing wrong with the socket. You're
>> asking it to send some data and, if the channel is busy, it's buffering
>> it.
>> When the buffer is full (because you're trying to send faster than the
>> network bandwidth will allow), it tosses the packets. That's exactly the
>> way I'd expect it to work. I bet that if you change the buffering, the
>> amount of data actually delivered will probably change right along with
>> the
>> buffer settings. You should be looking at the return value from SendTo()
>> to
>> verify that it's actually sending the bytes that you are providing. When
>> it
>> doesn't, you need to decide what to do about it...
>>
>> Paul T.
>>
>