| View previous topic :: View next topic |
| Author |
Message |
PGWARE Web Host

Joined: 29 Dec 2001 Posts: 1567
|
Posted: Thu Feb 26, 2004 8:48 pm Post subject: |
|
|
Hello,
Thanks for reporting this bug. It is now fixed; the default maximum packet size for UDP-SERVER/CLIENT within the dll is now at 8192 characters. Get the update at:
http://forum.vdsworld.com/viewtopic.php?p=18570#18570 |
|
| Back to top |
|
 |
bbelcher Contributor

Joined: 30 Jul 2002 Posts: 172
|
Posted: Thu Feb 26, 2004 8:51 pm Post subject: |
|
|
woo hooo rock on....
Thanks
So do I hear a discount comming  |
|
| Back to top |
|
 |
bbelcher Contributor

Joined: 30 Jul 2002 Posts: 172
|
Posted: Thu Feb 26, 2004 8:58 pm Post subject: |
|
|
PGWARE,
I gave your new version a spin and It works great...
Thanks again !!! |
|
| Back to top |
|
 |
PGWARE Web Host

Joined: 29 Dec 2001 Posts: 1567
|
Posted: Thu Feb 26, 2004 9:02 pm Post subject: |
|
|
Yes I had an extra line in the code which reprocessed the incoming data. Not sure why I had that in there but apparently it was causing data to get corrupted after 292 bytes. Removing that line defauled back to the 8192 character buffer size.
If you need larger then 8192 character bytes I can increase it. This value is set at 8192 to keep the amount of data not too high while still not too low. Thus you should keep a limit on it otherwise someone wishing to DDOS you can send massive packets (with alot of data) to the UDP server thus halting it from operation. |
|
| Back to top |
|
 |
bbelcher Contributor

Joined: 30 Jul 2002 Posts: 172
|
Posted: Thu Feb 26, 2004 9:07 pm Post subject: |
|
|
for my current project 8192 is just fine.. But I do like the posibility of incressing it.
Thanks! |
|
| Back to top |
|
 |
PGWARE Web Host

Joined: 29 Dec 2001 Posts: 1567
|
Posted: Thu Feb 26, 2004 10:51 pm Post subject: |
|
|
| 8192 characters is awfully alot of text to send as one message. I know over the internet if you try that with UDP you're guaranteed to miss alot of that packet. |
|
| Back to top |
|
 |
Rebel49 Contributor


Joined: 23 Aug 2002 Posts: 78 Location: Nova Scotia, Canada
|
Posted: Fri Feb 27, 2004 11:58 am Post subject: |
|
|
PGWARE wrote
| Quote: | Yes I had an extra line in the code which reprocessed the incoming data. Not sure why I had that in there but apparently it was causing data to get corrupted after 292 bytes. Removing that line defauled back to the 8192 character buffer size.
|
I have encountered troubles in the past while assembling SNMP multiple GET REQUESTS that I seemed to reach a limit at around 5 or 6 requests per packet. I assumed it was a buffer limitation . So this update may help me expand SNMP capabilities with VDSIPP. I will be interested in trying this out. But it may have to wait until the 12th of never the way things are going.
Thanks for the update!
REB _________________ OLD and eager! |
|
| Back to top |
|
 |
bbelcher Contributor

Joined: 30 Jul 2002 Posts: 172
|
Posted: Fri Feb 27, 2004 8:48 pm Post subject: |
|
|
Any one know how to use the INTERNET REPLACENULL, ON command.
What I'm looking for is a simple way to parse out the line between the ^NULL^
I've tried
OPTION FIELDSEP, ^NULL^
OPTION FIELDSEP, @chr(0)
OPTION FIELDSEP, @chr(34)^NULL^@chr(34)
OPTION FIELDSEP, @chr(94)NULL@chr(94)
I must be missing the obvious. |
|
| Back to top |
|
 |
Garrett Moderator Team
Joined: 04 Oct 2001 Posts: 2150 Location: A House
|
Posted: Fri Feb 27, 2004 8:58 pm Post subject: |
|
|
I would just fieldsep the ^ character. Then parse like this:
PARSE "%A;%B;%C",%%IncomingData
%A and %B would contain all data on the outsides of the ^NULL^
You might consider doing an @match() first if all this data is in a list
to make sure that the line has that in it first before trying to parse it.
Or if you are just using strings maybe use the @pos() to see if the ^
character is in the string before you try to parse it. _________________ 'What you do not want done to yourself, do not do to others.' - Confucius (550 b.c. to 479 b.c.) |
|
| Back to top |
|
 |
|