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
[EMAIL PROTECTED] 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 ...
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.1/348 - Release Date: 25/05/2006
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
