TIPI and Mass Transfer

[+InsaneMultitasker]

Beery is there a later version of the TIPI enabled MXT software?  The version you posted is working like Omega's video (a good thing) but the IBM graphics don't show up.  I plan to use 80 columns so its not a big deal,just curious.  I know you've done a lot of other work on various TIPI-enabled programs since this was released.

[+9640News]

No, I never did any further work.  I was hoping to find the source for the 80 column version, but never came across it.

 

Beery

 

[+InsaneMultitasker]

On 9/30/2018 at 8:02 PM, BeeryMiller said:

 

Hopefully this works.

MXT20180929.zip 72.28 kB · 22 downloads

 

Updated a few things while playing around with TIPI code.  This version displays top-down, displays IBM graphics characters 128-255, has a few VDP speed enhancements, and implements buffering.  If you hold CTRL-SHIFT, the display will immediately pause until you release, just like TIMXT. (you will probably need this feature now).  File transfers don't work for me; the same thing happens with the released ZIP above.  I inspected the IAC-related code and it looked OK, so I'm not sure what's going on. Edit: I connected to 9640news TIPI BBS and with IAC off, was able to download a file, so the earlier issue may be with my internal network. Not really sure.

 

Since I achieved what I wanted to learn with this code, I don't plan to do any more updating at this time.   Compatible with the phone files, etc in Beery's ZIP.

 

See next post for updated files

 

 

 

 

[+InsaneMultitasker]

Updated the data buffering to conform to M@'s tipi message expectations. Also found a spot where interrupts were enabled during a VDP operation.  (Deleted files from post 53).  And yes, these are TIFILES format copied directly from my tipi folder.    (Files deleted, will update later today)

 

 

[+InsaneMultitasker]

OK... Thanks to @jedimatt42's earlier direction and @Stuart's code examples, I have added "connecting..." text and error trapping to the two connection routines.  If the target URL is busy, mass transfer responds immediately with an error.  If the URL/port doesn't respond or is not valid, it takes a minute [two minutes according to the log] or so for the response to come back.  I posted a message in the Heatwave topic (unwittingly) about this earlier, as NET\TELNET exhibits the same behavior.  

 

The log via PUTTY shows quite a few of the same socket entries.  I am not polling or repeating my message/read, so my uninformed guess is that the TIPI or RPi side is doing so until the timeout occurs.  I'll do a little more testing after I tend to the Geneve.
2020-06-06 14:22:36,808 TiSocket    : INFO     socket not open: 0
2020-06-06 14:22:36,811 TiSocket    : INFO     socket not open: 0
2020-06-06 14:22:36,815 TiSocket    : INFO     socket not open: 0
 

Edit: also added a simple test to check the URL length and first char for null/space, as TIPI doesn't recover when Mass Transfer passes all spaces in the url string.  (Whether this is a Mass Transfer or TIPI issue, I don't yet know).  This might be a clue, I'll do more testing then post in the TIPI support forum. Maybe lack of port number causes it.

 

2020-06-06 14:51:12,638 TipiService : ERROR    Unhandled exception in main
Traceback (most recent call last):
  File "./TipiService.py", line 64, in <module>
    if rawExtensions.handle(msg):
  File "/home/tipi/tipi/services/RawExtensions.py", line 22, in handle
    return handler.handle(bytes)
  File "/home/tipi/tipi/services/TiSocket.py", line 55, in handle
    self.tipi_io.send(self.processRequest(bytes))
  File "/home/tipi/tipi/services/TiSocket.py", line 62, in processRequest
    return commandHandler(bytes)
  File "/home/tipi/tipi/services/TiSocket.py", line 75, in handleOpen
    port = int(params[1])
IndexError: list index out of range
 

[+jedimatt42]

I don't really understand the term URL in this context... you are just supposed to pass a hostname and port to the open command for the TCP extension:

 

open	0x22 + handle-byte + 0x01 + "hostname:port"

 

they must be separated by a colon... The crash happens cause you are opening a socket and there is no default port value. The TCP extension doesn't implement an application layer TCP protocol like TELNET or HTTP, just a bare socket. So it has no idea what a default port is.

 

I can fix TIPI so that it reports a connection error instead of crashing.. but a port will always be required. 

[+InsaneMultitasker]

I understand the port is necessary for the open command, as is the hostname.  I'm simply used to the term 'hostname' referring only to the local system's name.  I see where URL is problematic.  Semantics and correctness aside, Mass Transfer should not be allowed to pass an open request without a port, however, I wasn't expecting the crash.

 

On a related note I lifted your recvmsg code from the TIPI DSR to test an idea.  I added a simple timer (two DEC loops) within the handshake code so that if the timer expires before the handshake occurs, a tipi 'powerup' is executed and GPLWS R0 is cleared.  When Mass Transfer tries to open a port, I call this 'special' routine, the timer spins for 5 seconds and if there is no response, the TIPI is reset and control is returned to try again. 

[+jedimatt42]

Would that 'timer' be necessary if I fixed the error handling on the PI side? 

 

I suppose that is a fast fail if for instance the host and port are valid, and you connect to present, but non-responsive remote server.

[+InsaneMultitasker]

Ok, enough fun for one day. This version implements a few safeguards though you can still pass a hostname without a port. User beware.   The modified recvmsg routine is called only when opening a new connection.  Connecting status is shown for manual and auto connections.    Menu option (R) is now (C) for connect.  Letter (A) is for the automatic 'phone' list, which now stays within the 'dialer' if the connection timed out/errored out, so that you can select another option or try again.  Sorry, I did not implement a "redial" feature.  

 

MXT4B

MXT4A

[Omega-TI]

I'll try and find a few minutes tomorrow to play with it.  I think I'll have to call in with the TELNET program first to change to 40 column non ANSI.

[+InsaneMultitasker]

1 hour ago, jedimatt42 said:

Would that 'timer' be necessary if I fixed the error handling on the PI side? 

 

I suppose that is a fast fail if for instance the host and port are valid, and you connect to present, but non-responsive remote server.

I don't think that the timeout routine is necessary for the port-specific error, especially if you adjust the PI side.  And I 'm not for certain the timeout would even recover from a port error condition; the log shows that in at least one port error instance, the TIPI reset itself yet the TI was hung.  

 

The situations I find the timeout useful are when the host is valid yet there is no response or no response at the specified port.  I don't know if there are any other timeout scenarios worth considering, such as an error during a TIPI operation that is unrecoverable?  With the SCSI card, I have experienced times when the target device doesn't respond in time, locking the bus and the system, never to recover;  and of course it always seems (seemed) to happen while saving a file.  Beyond the 'open' case, the timeout is probably a solution looking for a problem.

 

[+9640News]

Tim,

 

I have noticed in the past that sometimes when connecting to AfterHours, if a previous caller timed out, a new Telnet connection is established, but it may take some time (I have seen even a minute) before the server TIPI responds.  On the client side (doesn't matter if TIPI or not), it just sits there waiting for the socket to be recognized on the server side.  I haven't had time to observe this situation with the last two or three upgrades and/or AfterHours server updates to know if this particular issue is still present or not.

 

Beery

 

[+InsaneMultitasker]

16 hours ago, Omega-TI said:

I'll try and find a few minutes tomorrow to play with it.  I think I'll have to call in with the TELNET program first to change to 40 column non ANSI.

Sounds good, let us know the results.  You can retain the ibm graphics as those will now display in the terminal.  I thought about grafting part of TIMXT's interpreter into the program but 40 column windowing isn't something I wanted to mess with right now.  I logged into 9640news TIPI BBS at port 9918 as well as Heatwave, both at 40 columns.