Shell Socketed

[skindoc4]

I have observed some strange behaviour using the following handlers:

on chatConnect
--1) put line 2 of fIPList() & ":1987" into s
--2) put "192.168.1.12:1987" into s

******
Line 1 and 2 each put the same string into s. Line 1 is derived using the shell script whilst line 2 is as is. Uncomment Line 2 and everything works perfectly, whilst uncommenting Line 1 produces very strange behaviour - an HTML-tagged string ending up in the message delivered to the "chatConnected" handler.

Can anyone assist with an explanation for this. My work-around is to "hard-wire" the IP addresses for the time being but I was looking for a method of "discovering" the Server on the network every time a new user wants to connect.

It took simply ages to work out that invoking the shell routine seemed to precipitate this odd behaviour.

Alex
****************


open socket s with message "chatConnected"
end chatConnect

--returns a list of the available computer IPs on the LAN
--quick and dirty routine but does the job
function fIPList

*******
put shell("arp -a") into myVar
*******

filter myVar without "*incomplete*"
delete the first line of myVar

put empty into aList
repeat with i = 1 to the number of lines in myVar
get line i of myVar
set the itemdel to "("
get item 2 of it
set the itemdel to ")"
get item 1 of it
put it & cr after aList
end repeat
return aList
end fIPList

[Mark Smith]

Your fIPlist is returning a string with a trailing newline, which may well be causing the problem - try:

return char 1 to -2 of aList (so losing the trailing newline).

Best,

Mark

[skindoc4]

Hi Mark

Thanks. Now I know for sure what the problem was. I eventually figured it might be something that I couldn't see so I went back to Alex Tweedly's example and discovered this:

filter with "*IPAddress*"

It gets rid of nasty things.

With a slightly different use of the "arp" command I got the list I was after.

I am still having trouble implementing sockets however. What I want to do is locate the Server computer on my network when clients try to connect ie. the client needs to be able to discover the IP of the Server computer.

My messageReceived handlers seem to be out of sync with the progression of statements in the handlers which do the reads from sockets which means I have no way of flagging a successful connection before the calling handler finishes. I am still to find a way of doing this.

This has been more of a learning curve than I expected having just migrated from using REALBasic. But I never did tackle sockets in REALBasic so I suspect it is the nature of asynchonous communication that creates such difficulties.

Alex

[ceg]

Coming in late to this discussion, but clearly I see a couple of challenges with discovering local server (as with any network discovery):

(i) need to find the open port on the server (i.e. need to be able to either use something like "portmapper" to discover a port, or attempt an open)

(ii) need to be able to parse potential IP addresses (as arp will only show "active" ethernet/IP maps, so may not discover all potential addresses) - this parsing needs to recognise Class B/Class C addresses or even smaller from the netmask

(iii) need to avoid firewalls from detecting a Denial of Service (DoS) attack - probably need to check IP addresses in a random order and be careful not to flood the network with ICMP or TCP/UDP connection attempts

Just some thoughts on determining the best algorithm.