How to mimic telnet session

[Jan Schenkel]

--- RGould8 at aol.com wrote:
> I've been searching the Revolution archives, and I 
> think I'm close, 
> but I need some assistance figuring out what I'm 
> missing.  
> 
> Basically, I need to mimic a telnet session in 
> Revolution.  
> I need to send text commands to a server on the
> internet  via port 7777, 
> and receive the data that comes back.
> 
> 
> If I were  doing this manually, I'd type:
> 
> telnet dins.gte.net 7777
> 
> and then  type "cmd=getAccessType"
> 
> and then the server responds  with
> 
>
cmd=getAccessType&errorCode=NOERROR&count=7&1=28.8K&2=33.6K&3=33.6K,
>  
> ISDN&4=33.6K, ISDN, V.90&5=33.6K, V.90&6=ISDN 
> Only&7=V.90
> 
> 
> (you can try this as well, if you're on a live 
> connection)
> 
> 
> 
> Can anyone tell me what I'm missing in my code?   
> When I click the button, it seems to send
> successfully, but I get nothing  
> back...
> 
> 
> on mouseUp
> open socket "dins.gte.net:7777"  
> write "cmd=getAccessType"  & CRLF to socket 
> "dins.gte.net:7777" with message 
> "callbackmsg"
> wait 3  seconds
> read from socket "dins.gte.net:7777" for 80 with
> message  "gotData"
> close socket "dins.gte.et:7777"
> end  mouseUp
> 
> 
> on callbackmsg data 
> put "callback (the result) = "  & the result
> end callbackmsg
> 
> on socketError
> answer "got  an error"
> end socketError
> 
> on gotData
> put "databack (the  result) = " & the result
> end  gotData
> 
> 

Hi,

The main problem with your code is that you are mixing
callbacks with wait statements that don't allow the
messages to be sent : 
  wait 3 seconds
will effectively freeze the engine, and the callback
will not be sent to the button. Then you try to read
from the socket before everything has been sent
through, which means that you can't read from the
socket yet.

Generalising quite a bit, there are two ways of using
sockets : using callbacks and not using them. Let's
start by fixing your code up without callbacks :
--
on mouseUp
  put "dins.gte.net:7777" into tSocket
  open socket tSocket
  write "cmd=getAccessType" & CRLF to socket tSocket
  read from socket tSOcket until empty
  put "databack (it) = " & it
  close socket tSocket
end mouseUp
--

As you can see, there's no neason to insert a wait
statement -- unfortunately, clicking the button will
suspend your entire application.
Now let's see how we can use callbacks to allow the
rest of the stack to operate properly.
--
on mouseUp
  disable me
  put "dins.gte.net:7777" into tSocket
  open socket tSocket with message "ConnectionOpen"
end mouseUp

on ConnectionOpen pSocket
  write "cmd=getAccessType" & CRLF \
        to socket pSocket \
        with message "DataSent"
end ConnectionOpen

on DataSent pSocket
  read from socket pSocket until empty \
       with message "DataRead"
end DataSent

on DataRead pSocket, pData
  put "databack (pData) = " & pData
  close socket pSocket
  enable me
end DataRead

on socketError pSocket, pError
  answer error "There is a connection problem." \
     with "Debugging Info" or "Cancel"
  if it is "Debugging Info"
  then answer information pError
  close socket pSocket
  enable me
end socketError

on socketTimeout pSocket
  answer error "The connnection is not responding." \
     with "Keep Trying" or "Cancel"
  if it is "Cancel" then
    close socket pSocket
    enable me
  end if
end if
--

The main thing to learn from the above version is that
you'll string one callback message to another call to
read or write (apart from the error handlers).
The biggest advantage of this approach is that your
application can keep running and process events while
the engine is talking to the socket -- and by simply
disabling/enabling the button, you can prevent the
user from accidentally clicking twice.

Hope this helped,

Jan Schenkel.

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree