 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Andy
Guest
|
 Posted: Thu Nov 20, 2003 9:25 pm Post subject: TidUDPClient repatative send limit |
 |
|
I hope the following makes some sense to some one. If what I am doing seems
odd, its because I'm self taught/not the sharpest tool in the box !!..
I'm tying to send repetitively without receiving any data using
TidUDPClient.
I want to broadcast to all on the network immaterial of I.P noting there is
a
restriction in I.P range using Broadcast components.
TidUDPClient component is set thus:
BroadcastEnabled True
BufferSize 180192
Host 255.255.254.0 (all my P.Cs use this)
Name BlahBlah
Port UDPClient
ReceiveTimeout 0
Tag 0
My program works fine (video capture etc) until I try and send using the
following (the whole point of the program!):
UDPClient.Broadcast(CString, StrToInt(EditUdpPort.Text)); // the only use
of UDPClient component except bellow EditUdpPort.Text is 9193
I added the following in case there was an issue from ignoring any receive
event
Received := UDPClient.ReceiveString();
I am also testing using MemProof. Using memproof I can send about 40 -
60,000 images and in just windows 98 I can send around 250,000 images but
then writing to the hard drive occurs for every send, eventually the writing
to the drive slows the system to a halt. Testing in Delphi debugger gives
no errors and all seems well in memproof also. It just eventually stops.Does
anyone have any ideas?.
I am sure this problem has arisen since changing from Windows 95, but can't
be sure. Reducing memory seems to cause the problem to occur sooner.
I am converting Jpeg to string using the following: Please see the comment /
question
function TMain.JpgToStr(Jpg: TJpegImage): String;
var
memStream: TMemoryStream;
begin
Result := '';
if Jpg.Empty then Exit;
memStream := TMemoryStream.Create;
try
Jpg.SaveToStream(memStream);
///memStream.Position := 0; // Tried both, whichis
correct ?
memStream.Seek(0, soFromBeginning); // Tried both, which is correct?
SetLength(Result, memStream.Size);
memStream.Read(Pointer(Result)^, memStream.Size);
finally
memStream.Free;
end;
end;
Laters.......
Andy.
|
|
| Back to top |
|
 |
Remy Lebeau (TeamB)
Guest
|
| Posted: Thu Nov 20, 2003 9:46 pm Post subject: Re: TidUDPClient repatative send limit |
|
|
"Andy" <net1 (AT) freewire (DOT) co.uk> wrote
| Quote: | I am also testing using MemProof. Using memproof I can send about 40 -
60,000 images and in just windows 98 I can send around 250,000 images
but then writing to the hard drive occurs for every send, eventually the
writing to the drive slows the system to a halt.
|
That suggests to me that you have a memory leak somewhere that is eating up
all of the available memory until the OS has to switch over to using virtual
memory from the harddrive and then the leak eats up that memory as well, on
top of all of the file I/O now occuring as well, until the system can't take
anymore.
| Quote: | I am converting Jpeg to string
|
Why are you using a string? Can't you just send the jpg data directly?
Gambit
|
|
| Back to top |
|
|
Andy
Guest
|
| Posted: Thu Nov 20, 2003 10:00 pm Post subject: Re: TidUDPClient repatative send limit |
|
|
| Quote: | on top of all of the file I/O now occuring as well,
|
What do you mean here plz ?
I guessed it was a memory leak. Its driving me up the wall, I hook all sorts
to memproof but all seems well. I can see when I mess up as memproof gives
errors as the prog runs. it counts bmps and critical section amongst many
others. It does not reveal my problem. Winsock DLL is 4.10.1998
"Remy Lebeau (TeamB)" <gambit47.no.spam (AT) no (DOT) spam.yahoo.com> wrote
| Quote: |
"Andy" <net1 (AT) freewire (DOT) co.uk> wrote in message
news:3fbd3017 (AT) newsgroups (DOT) borland.com...
I am also testing using MemProof. Using memproof I can send about 40 -
60,000 images and in just windows 98 I can send around 250,000 images
but then writing to the hard drive occurs for every send, eventually the
writing to the drive slows the system to a halt.
That suggests to me that you have a memory leak somewhere that is eating
up
all of the available memory until the OS has to switch over to using
virtual
memory from the harddrive and then the leak eats up that memory as well,
on
top of all of the file I/O now occuring as well, until the system can't
take
anymore.
I am converting Jpeg to string
Why are you using a string? Can't you just send the jpg data directly?
Gambit
|
|
|
| Back to top |
|
|
Andy
Guest
|
| Posted: Thu Nov 20, 2003 10:18 pm Post subject: Re: TidUDPClient repatative send limit |
|
|
| Quote: | Why are you using a string? Can't you just send the jpg data directly?
|
Don't think it will broadcast anything else, just a string. I am using it
the wrong way round of course. I had thought it was a blocking socket issue
as its similar to what you see when using TidTCIP (or what ever called)
*outside* any while connected loop. TidUDP is connectionless though ?.
|
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Thu Nov 20, 2003 10:35 pm Post subject: Re: TidUDPClient repatative send limit |
|
|
"Andy" <net1 (AT) freewire (DOT) co.uk> wrote
| Quote: | on top of all of the file I/O now occuring as well,
What do you mean here plz ?
|
By "file I/O", I am referring to accessing the harddrive. Virtual memory
uses empty harddrive space as if it were physical memory, but the memory
still resides on the harddrive nontheless. Accessing the harddrive will
always be slower than accessing physical RAM memory.
Gambit
|
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Thu Nov 20, 2003 10:42 pm Post subject: Re: TidUDPClient repatative send limit |
|
|
"Andy" <net1 (AT) freewire (DOT) co.uk> wrote
| Quote: | Don't think it will broadcast anything else, just a string.
|
Everything is raw data as far as sockets are concerned. Even strings are
sent as raw data. TIdUDPClient has a SendBuffer() method which accepts an
untyped pointer to raw memory. All Broadcast() does is sets enables the
SO_BROADCAST flag via setsockopt(), then calls Send() (which in turn calls
SendBuffer()), and then removes the SO_BROADCAST flag. So instead of
calling Broadcast(), you could set the BroadcastEnabled property to true
(especially if all you are ever going to do is broadcasting) and then call
SendBuffer() directly instead of Broadcast/Send(). When calling
SendBuffer(), you can send it the TMemoryStream memory directly without
having to convert it to a string first.
Gambit
|
|
| Back to top |
|
|
Andy
Guest
|
| Posted: Fri Nov 21, 2003 12:44 am Post subject: Re: TidUDPClient repatative send limit |
|
|
| Quote: | Everything is raw data as far as sockets are concerned. Even strings are
sent as raw data. TIdUDPClient has a SendBuffer() method which accepts an
untyped pointer to raw memory. All Broadcast() does is sets enables the
SO_BROADCAST flag via setsockopt(), then calls Send() (which in turn calls
SendBuffer()), and then removes the SO_BROADCAST flag. So instead of
calling Broadcast(), you could set the BroadcastEnabled property to true
(especially if all you are ever going to do is broadcasting) and then call
SendBuffer() directly instead of Broadcast/Send(). When calling
SendBuffer(), you can send it the TMemoryStream memory directly without
having to convert it to a string first.
|
Have tried it as above before but I'm sure it didn't broadcast, only to one
specific I.P. I will try it again and see. It'll take a day or 2 even with
just 32 Meg ram, if it will actually broadcast. Thanks so far!.
|
|
| Back to top |
|
|
Andy
Guest
|
| Posted: Tue Nov 25, 2003 4:19 am Post subject: Re: TidUDPClient repatative send limit |
|
|
| Quote: | Everything is raw data as far as sockets are concerned. Even strings are
sent as raw data. TIdUDPClient has a SendBuffer() method which accepts an
untyped pointer to raw memory. All Broadcast() does is sets enables the
SO_BROADCAST flag via setsockopt(), then calls Send() (which in turn calls
SendBuffer()), and then removes the SO_BROADCAST flag. So instead of
calling Broadcast(), you could set the BroadcastEnabled property to true
(especially if all you are ever going to do is broadcasting) and then call
SendBuffer() directly instead of Broadcast/Send(). When calling
SendBuffer(), you can send it the TMemoryStream memory directly without
having to convert it to a string first.
|
My original attempt at broadcasting now works (apparently!). Have sent 1/2
million images and can still open apps and play network games with out any
problems what so ever. Even unplugged the hardware by accident (Doh) and it
recovered!.
I want to try your suggestion as above.
1) What settings should I use for the UDPClient?, in particular the Host
address. I am sure I could not broadcast using send buffer when I tried
before.
2) How can I make the Indy UDPserver send (Broadcast), without having to
receive something first?.
3) How can I make the Cast server and Client work on any I.P, instead of the
limited range?.
Thanks,
Andy
|
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Tue Nov 25, 2003 4:25 am Post subject: Re: TidUDPClient repatative send limit |
|
|
"Andy" <net1 (AT) freewire (DOT) co.uk> wrote
| Quote: | 1) What settings should I use for the UDPClient?
|
I already told you that earlier. Just set the BroadcastEnabled property to
true.
| Quote: | in particular the Host address.
|
The Host address is not used during broadcasting, the packets are sent to
the subnet instead.
| Quote: | 2) How can I make the Indy UDPserver send (Broadcast),
without having to receive something first?.
|
Just send. Sending and receiving are two completely separate and
independant operations.
Gambit
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
