A S@H quickie! ,does v3.03 work with SETIQ 78b?

[Assimilator1]

I ought to know the answer to this ! ,but for the life of me I can't remember!

I'll be upgrading a remote client to v3.03 tonight ,it uses SETIQ ,I may not have a chance to access it again for up to 1 week

 

[blade47]

It will work just fine for now, but as soon as the new clients are mandatory it will not work unless you change the address SetiQ connects to, which btw I don't know. The new client uses a different address for the server than the old ones did. SetiQ uses the old address as well, so once they cut off the old address setiQ won't be able to find the server.

SetiGate will work but you have to manually enter the new server address, that is unless they've updated the software to already use the new address. SetiDriver will also work just fine with the new client without you having to do anything.

Edit: I guess I should have included that I'm currently running 3 machines with v3.03 connecting to SetiQ without doing anything to SetiQ. I think what Ken said is correct. All you have to do in SetiGate is change the server address it connects to & SetiQ will let you do the same thing so I would assume it will work.

 

[Ken g6]

No. ... At least, it's not supposed to be able to. <dangit, where is that evil grin?>

The problem is that 3.03 uses a different server from the previous clients. I've set my SetiQ up with the following line in qseti.txt to point to the new server:

proxy_server=shserver2.ssl.berkeley.edu

I'll admint I'm not running 3.03 yet, but I think this would work. And it does work with 3.0. Care to be a guinea pig?

 

[Assimilator1]

Thanks guys ,I knew about the upcoming server switch ,just wasn't sure about v3.03+SETIQ.

The hack BTW is to put the new SETI server IP in a hosts.txt file in the windows directory to redirect SETIQ.

KenG6

*squeak squeak*! ,I'll let you know if disastor strikes!

Thanks for the quick info again ,I'm off out now

 

[Sisyfos]

Lets get this straight.
The old clients (incl. SetiQ) are looking for shserver.ssl.berkeley.edu.

C:\>ping shserver.ssl.berkeley.edu

Pinging sagan.ssl.berkeley.edu [128.32.18.166] with 32 bytes of data:

Reply from 128.32.18.166: bytes=32 time=191ms TTL=239


v3.03 is looking for shserver2.ssl.berkeley.edu.

C:\>ping shserver2.ssl.berkeley.edu

Pinging sagan.ssl.berkeley.edu [128.32.18.166] with 32 bytes of data:

Reply from 128.32.18.166: bytes=32 time=180ms TTL=239


So what they are doing is deleting the old DNS entry.
The server and IP-address are the same, so the solution is to put
128.32.18.166 shserver.ssl.berkeley.edu
in the HOSTS file.
At least this is my understanding, but it just seems so easy to circumvent.

 

[Assimilator1]

Thanks ,I had a vague feeling they shared something!.
I'll save this post for when the time comes.