Problems with sockets with 3.6 Carbon VM?

Phil Hargett hargettp at mindspring.com
Wed Oct 8 11:00:23 UTC 2003


On Wednesday, October 8, 2003, at 03:08  AM, John M McIntosh wrote:
> Lets see first I couldn't get the
>
>>> ..... code here ...
>
> to run, that creates an array for machine, but the primitive wants a 
> bytearray and it invokes a primitive failed.
> So I changed it to
> machine _ NetNameResolver localHostAddress.
> which in my opinion is better than hard coding a magic number in any 
> case.
>
> I also had to change your connection logic to
> 	serverSocket _ Socket newTCP.
> 	serverSocket listenOn: 53811 backlogSize: 4.
> 	serverSocket semaphore wait.
> 	serverSocket isConnected
> 			ifTrue: [peerSocket := serverSocket accept.
> 					peerSocket inspect]

Yep, all those changes make sense; in fact, in my running code, that's 
essentially what I have.  I guess I chopped out too much when I created 
my snippet--especially the listenOn:backlogSize:, since that sets up 
the socket to allow multiple connections to be captured by a 
Socket>>accept: call.

>
> Now what I found was that the semaphore get signalled, then we invoke 
> the isConnected call
> isConnected
> 	"Return true if this socket is connected."
>
> 	socketHandle == nil ifTrue: [^ false].
> 	^ (self primSocketConnectionStatus: socketHandle) == Connected
>
> which asks for the connection status, then it does the follow C code. 
> You'll note that the Server Socket State is Connected, however
> it's NOT readable, thus the socket state goes to OtherEndClosed.
> This returned results fails the if block because it's not equal to 
> Connected.
>
> I can't comment on what the real logic should be. MMM I do note this 
> *was* the change that Ian made on the 16th to the source.
> I'll invite more comment? Perhaps a linux user can try with a swiki 
> and see what happens?
>

Interesting...so perhaps the problem is with the call to 
Socket>>primSocketConnectionStatus:?  That would make sense; I can see 
the C plugin code is successfully executing an accept() on the socket, 
so it would appear there is a connection ready to use.

Running another test, I tried the doIts that Ian sent me (and the 
list), I receive similar results to the above.  That is, the VM using 
sqUnixSocket.c does not appear to receive a connection, and the VM 
using sqMacNetwork.c does.  Here are the doIts used:

---------------- server

| port timeout serverSocket clientSocket | [
port := 5131.
timeout := 10000.
serverSocket := Socket newTCP.
serverSocket listenOn: port backlogSize: 30.
Transcript cr; show: 'listening'.
clientSocket := serverSocket waitForAcceptFor: timeout ifTimedOut: 
[nil].
Transcript cr; show: 'accepted ' , clientSocket printString, ' from ' , 
serverSocket printString.
(Delay forSeconds: 2) wait.
serverSocket close; destroy.
clientSocket close; destroy.
] fork.

---------------- client

| timeout machine port socket | timeout := 10000.
machine := #(127 0 0 1) asByteArray.
port := 5131.
socket := Socket newTCP.
socket connectTo: machine port: port.
socket waitForConnectionFor: timeout.
Transcript cr; show: 'connected ' , socket printString.
(Delay forSeconds: 2) wait.
socket close; destroy.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3215 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20031008/1fba2aa1/attachment.bin


More information about the Squeak-dev mailing list