Now a TCP Question

[Jim Ault]

Thanks go out to Alex Tweedly, as he kindly and generously invited me to
phone him about this complex issue.  We had a very good in-depth
conversation about the limitations of this TCP server in this instance.

Rather than try to troubleshoot that setup on the server end (since I have
no control over it), Alex concluded that using the UDP protocol would be the
best route.

Friday afternoon I installed rev 2.7.1 build 236 and tried running the stack
Alex had written (UDP echo server that listens for packets), and encountered
a crash within a one second of starting.

HOWEVER, if I compiled the stack and ran the app, it seemed to work fine.
This test was very short, and on Sat I will do a full-day test that will
include writing only the incoming messages I need to a series of text files.

I am optimistic that I can not only get the UDP server app to run all day,
but handle the influx of several messages in one tick (1/60th of a second).
Alex says that a rate of 100-150 packets per second is not a very high rate
for UDP, so the operating system should be able to buffer all packets and
the Rev app will keep up.

An additional advantage for me is that the stream of packets is mostly done
in a burst, rather than a steady rate.  OSX buffering should be able to do
the job.

A future advantage is that when a binary version of Rev is available, the
Duo Mini will be even faster.

If anyone is interested, I can post a report here, otherwise I will not
waste the list bandwidth in this niche application of Rev.

The power and flexibility of Revolution has not ceased to amaze me.

Jim Ault
Las Vegas


On 5/26/06 1:47 PM, "Alex Tweedly" <alex at tweedly.net> wrote:

> Jim Ault wrote:
> 
>> It turns out that the server service has just started a TCP alternative, so
>> I tried Alex Tweedly's TCP server and client.
>> 
>> These two stacks run successfully on both the same computer and two that I
>> have on my network, either with DHCP address or each having a static IP
>> address.
>> 
>> Now the outside world...
>> Adjusting firewall and my client settings, I can get
>> 
>> "Success: opened server.i.p.addr:8882"
>> 
>>  
>> 
> Jim - that looks like a message from my "client" stack.
> What is running on the remote server ?
> 
>> where the actual IP address is shown, so I assume this is a handshake.
>> 
>>  
>> 
> That means the connection was successfully opened.
> 
>> The tech group reports back that (including word wrap, addr chgd) :
>> --------------------------------------------------------------
>> We are seeing the following in the sdlear/tcpip log:
>> 
>> 060526 08:16:19 Accepting TCP Connection from dd.234.99.999:33142
>> 060526 08:17:42 send error: WSACONNABORTED
>> 060526 08:17:42 Releasing TCP Connection from dd.234.99.999:33142 (0
>> 00:01:23)
>> 060526 08:24:04 Accepting TCP Connection from 24.234.99.999:32776
>> 060526 08:38:50 send error: WSACONNABORTED
>> 060526 08:38:50 Releasing TCP Connection from 24.234.99.999:32776 (0
>> 00:14:46)
>>  
>> 
> Hmmm - but this one has been connected for 14 minutes, so it doesn't
> look like it's a firewall issue (it still could be, but much less likely).
> 
> Have the client and server been exchanging data for this 14 minutes ?
> 
>> 060526 09:04:25 Accepting TCP Connection from 24.234.99.999:32832
>> 060526 09:05:27 Accepting TCP Connection from 24.234.99.999:32834
>> 060526 09:05:32 send error: WSACONNABORTED
>> 060526 09:05:32 Releasing TCP Connection from 24.234.99.999:32832 (0
>> 00:01:07)
>>  
>> 
> This one, like the first on, failed after just over 1 minute.
> Is this talking to the service's server ? Could it be closing the
> connection because it doesn't receive an (application level) response
> within a time window ?
> 
>> 060526 09:10:52 Accepting TCP Connection from 24.234.99.999:63559
>> 
>> 
>> WSAECONNABORTED (10053)
>> €Translation: Software caused connection abort.
>> €Description: An established connection was stopped by the software in your
>> host computer, possibly because of a data transmission time-out or protocol
>> error.
>> ------------------------------------------------------
>> I get this both on
>> G5 dual, OSX 10.4.6, Rev 2.6.1
>> Duo Mini, OSX 10.4.6, Rev 2.6.1 or 2.7.1  build 236
>> 
>> This is getting a little deep for me, since I am not a networking or socket
>> guy.  It seems that Rev is almost up to the task.  If I can figure this out,
>> I will put together some example and test stacks so others can learn.  I
>> could possibly host some stacks for live testing that others could use.
>> 
>> My deadline for getting this solved is about 5 days from now, so hopefully I
>> can learn all the details I need to make this happen.
>> 
>> Questions:
>> Since UDP works on the G5/10.4.6, but not DuoMini/10.4.6
>> [starts to get messages, then crashes Rev w/EXEC_BAD_INSTRUCTION (0x0002)]
>> on BOTH  2.6.1 and  (2.7.1 build 236 installed today 5.26.06)
>> Since TCP would be the most desirable method, is there a test server I can
>> use?
>>  
>> 
> Can you be a little bit more explicit about the set up ? What is the
> client sending ? Does it receive any response ?
> Is the server the general one that the service is running ?
> 
> Unfortunately, I don't have a host directly on the Net, so can't accept
> incoming connections.
> 
> If it would help (and if there's not a confidentiality issue), send me
> the stack you are using and I'll experiment (send it direct to
> alex at tweedly net )
> 
> If you want, call me +44 1852 200212 - and *remember* I'm 7 or 8 hours
> ahead :-)
> OK to call up till 1am but not much after that ...