Re: NTK 32K limit in TCP Receive

Yeah, can you imagine how they could have sold and marketed 4D with A4D built in? Nothing on the market would have come close. > On Apr 10, 2020, at 5:03 PM, James Wright via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > So should Active4D! ***

Re: NTK 32K limit in TCP Receive

So should Active4D! On Fri, 10 Apr 2020 at 21:58, Jeffrey Kain via 4D_Tech <4d_tech@lists.4d.com> wrote: > :) > > I miss the days of lots of thriving plug-ins. NTK should really be built > into 4D. > > > On Apr 10, 2020, at 4:49 PM, Aparajita Fishman via 4D_Tech < > 4d_tech@lists.4d.com> wrote:

Re: NTK 32K limit in TCP Receive

:) I miss the days of lots of thriving plug-ins. NTK should really be built into 4D. > On Apr 10, 2020, at 4:49 PM, Aparajita Fishman via 4D_Tech > <4d_tech@lists.4d.com> wrote: > >> Overreact much? > > Yes, I do. All the time unfortunately. > > We plugin authors are a dying breed. I plead

Re: NTK 32K limit in TCP Receive

>> The documentation clearly says 32000 is the default maximum to read if you >> **DON’T** specify the maximum. So I have to agree with Rob — what exactly is >> the problem? Is it really so difficult to type a few more characters to >> override the default? > > You can specify a larger maximum

Re: NTK 32K limit in TCP Receive

> On Apr 10, 2020, at 1:09 PM, Aparajita Fishman via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > The documentation clearly says 32000 is the default maximum to read if you > **DON’T** specify the maximum. So I have to agree with Rob — what exactly is > the problem? Is it really so difficult to

Re: NTK 32K limit in TCP Receive

> On 10 Apr 2020, at 18:03, Jeffrey Kain via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > First, the maximum size of a text variable isn't 32000 bytes anymore, which > leads me to believe this was an oversight and not a feature... :) Yes, I know. But it’s not related. It is just a convenient d

Re: NTK 32K limit in TCP Receive

>> On 9 Apr 2020, at 20:46, Jeffrey Kain via 4D_Tech <4d_tech@lists.4d.com >> > wrote: >> >> Why? :) > > Why not? > > The data that is available from the stream can be any arbitrary size. The > plugin does not know upfront how many bytes are available, so it needs

Re: NTK 32K limit in TCP Receive

Two problems; First, the maximum size of a text variable isn't 32000 bytes anymore, which leads me to believe this was an oversight and not a feature... :) Second, it was easy to receive text until a stop character is received, as long as the data is less than 32K. When your packets become lar

Re: NTK 32K limit in TCP Receive

> On 9 Apr 2020, at 20:46, Jeffrey Kain via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Why? :) Why not? The data that is available from the stream can be any arbitrary size. The plugin does not know upfront how many bytes are available, so it needs a limit. There is a default value, which

Re: NTK 32K limit in TCP Receive

Jeff: Anecdotally, 4D IC is based on PDM’s Internet Tools which dates back to the early 90’s (PDM was started by a few of the original ACI employees from the 80’s). Quite a bit of the code was updated but perhaps that’s one item that’s not been up to speed…er, size. -- Douglas von Roeder 949-910-

Re: NTK 32K limit in TCP Receive

Nope, it's for real. Easy enough to loop, etc.. But it's a bit of an anachronism in a modern plug-in like NTK. > On Apr 9, 2020, at 4:24 PM, Ben Kershaw via 4D_Tech <4d_tech@lists.4d.com> > wrote: > >> Why? :) >> "The bufferSize parameter indicates the maximum number of bytes to read. If >> i

Re: NTK 32K limit in TCP Receive

Jeffrey Kain wrote: >Why? :) >"The bufferSize parameter indicates the maximum number of bytes to read. If it >is omitted or set to 0, the plugin will use the maximum size for a text >variable (32000 bytes).” Have you tested it to make sure it’s not just a documentation error? Regards, Ben Kers

NTK 32K limit in TCP Receive

Why? :) "The bufferSize parameter indicates the maximum number of bytes to read. If it is omitted or set to 0, the plugin will use the maximum size for a text variable (32000 bytes)." ** 4D Internet Users Group (4D iNUG) Archive