Re: QLink Reloaded

From: Tod D. Ihde <tihde_at_warmerbythelake.com>
Date: Sun, 15 Apr 2012 18:39:07 -0500
Message-ID: <4F8B5C1B.1090505@warmerbythelake.com>
On 4/15/2012 12:07 PM, James L. Mazurek wrote:
> On Sun, Apr 15, 2012 at 4:04 AM, Tod D. Ihde <tihde@warmerbythelake.com
> <mailto:tihde@warmerbythelake.com>> wrote:
>
>     On 4/15/2012 2:34 AM, Tod D. Ihde wrote:
>
>         On 4/15/2012 2:11 AM, James L. Mazurek wrote:
>
>             On Sun, Apr 15, 2012 at 1:11 AM, Tod D. Ihde
>             <tihde@warmerbythelake.com <mailto:tihde@warmerbythelake.com>
>             <mailto:tihde@warmerbythelake.__com
>             <mailto:tihde@warmerbythelake.com>>> wrote:
>
>             James,
>
>             Wow! Thanks for the info!
>
>             I grabbed ShadowM's repository, and followed Mike's instructions
>             for setting up the DB. I also followed his instructions as a
>             test
>             (compile in eclipse, same result on // issuance. export
>             build.xml,
>             compile with ant, same results again).
>
>             I know there's a bug with //who - but I can't get my server
>             build to
>             issue any // command without Vice / x64 bailing to a warm boot.
>             (Yes, I am using an emulator. I don't have an RS-232 port
>             for my 64,
>             so Vice was the best option for me).
>
>             Tod.
>
>             ps.
>
>             Sorry, I top-post. Feel free to yell, I can bottom-post as well.
>
>
>             Tod,
>
>             I don't know that there is any difference between ShadowM's
>             and Mike's
>             repositories. I guess not at the moment. I have not tried to
>             build
>             directly with Eclipse and have very little interest in doing so.
>             Otherwise, our build processes via ant are the same. I
>             suspect if the
>             Eclipse environment and code project are set up correctly
>             the build
>             results should be effectively the same.
>
>             I have never really investigated the // command issues. I'll
>             see if I
>             can reproduce your results and get back to you. I'll see if
>             I can test
>             on real hardware as well. VICE has known issues using nc to
>             attach a
>             TCP connection to an emulated RS-232 port.
>
>             -Jim
>
>
>         Jim,
>
>         ...And now I'm bottom posting. :-D
>
>         Would you mind giving me a link to Mike's page / repo ?
>
>         I stumbled onto this when I decided to have a crack at fixing //who.
>         Silly me.
>
>         That would be fantastic! I can expose my server to the outside
>         world if
>         you want to try connecting to that, as well.
>
>         Oh? Can you expand on that? I've used netcat very successfully
>         with it,
>         as long as you remember to not use a source port ( -p ), and ALT-F12
>         (hard reset) between runs, it works well. Other areas of QLink
>         seem to
>         work just fine, and connecting to ShadowM's server allows me to
>         use //
>         commands as well.
>
>         Tod.
>
>
>         Message was sent through the cbm-hackers mailing list
>
>
>     Jim, James,
>
>     One final note, and I'm sorry I forgot to mention this.
>
>     One a clean check-out from SVN, all // commands work as expected.
>     Once I edit AbstractChatState.java at all, including changing a log
>     messag, the // commands start doing what I have described.
>
>     Sorry - this has me baffled.
>
>
>       Tod.
>
>
> Tod,
>
> Jim would you like to share the repository information with Tod?
> Otherwise, I'll verify that Mike's and ShadowM's repositories match.
>
> Have you tried a clean rebuild after you make your changes?  Just on the
> off hand chance something is not being recompiled correctly.
>
> I would avoid exposing your server.  The account creation & validation
> code is currently a little draconian.  If someone connects to your QLR
> server using a client disk validated at lyonlabs.org:5190
> <http://lyonlabs.org:5190> your server will overwrite their account data
> on their disk preventing them from being able to connect to their
> original account on lyonlabs.org:5190 <http://lyonlabs.org:5190>. So
> until I get the new user / validation code I've been working on tested,
> approved and committed it is not a good idea to have multiple QLR
> servers running live on "The Net".
>
> As far as the VICE & Netcat issue goes, it seems to be prone to packet
> loss that causes either undefined states in the Q-Link client that
> causes it to hang (most notably during login) or undefined states that
> hang the RS-232 emulated device (common when it first establishes the
> initial TCP connection).  In the case of the VICE/RS-232 issue, it often
> persists between hard resets of VICE.  Perhaps my issue is that I'm
> using old verions of VICE (whichever versions that are bundled with
> Debian Squeeze and Ubuntu Lucid) and the use of the source port option
> -p.  I was always led to believe the -p option was necessary in VICE.
> Perhaps not.  The moral of the story is VICE is a useful tool but I
> consider it a second class citizen so to speak and I don't want to
> invest a lot of time trying to resolve VICE issues in favor of real
> hardware.
>
> I'll try to do some testing later tonight and get back to you.
>
> -Jim

James,

  I clean & rebuild after every save, if that's what you mean.

I will leave it firewalled, but if you decide you want to poke it with a 
stick or something, just let me know. Yeah - I saw that issue myself 
with my lyonlabs.org disk. Thankfully I realized what was going on and 
reset before filling anything out...

Thanks for the info on netcat. I myself haven't had an issue with it, 
but then I'm running it local loopback most of the time (with an 
occasional stop at lyonlabs.org to verify working vs. mine).

My version of Vice always kills the exec pipe between hard resets, so 
perhaps the code is newer (Debian 6, Vice 2.2). The source port option 
for nc isn't needed with vice, since neither the QLR server not Vice 
checks to see what the originating port is. Best to let the kernel 
randomly assign an open source port, it does away with the port in use 
errors.

I know, Vice is not ideal, but as I said, I didn't have an RS-232 port 
for the C64, and I wasn't expecting this... So, now I'm on ebay buying 
parts to make an RS-232 adapter. :-D I'll have to suffer with Vice until 
they arrive though.

Excellent. I'll be around all night, putzing. Thanks!

  Tod.

       Message was sent through the cbm-hackers mailing list
Received on 2012-04-16 00:00:05

Archive generated by hypermail 2.2.0.