Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ zchat-connections being randomly denied
|
zchat-connections being randomly denied
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| j0nas
(56 posts) Bio
|
| Date
| Fri 02 Apr 2004 10:21 PM (UTC) |
| Message
| For various reasons, I've ended up writing a Java-client that communicates with MUSHClient using the zchat-protocol, and so far I'm well-pleased with the results, except for one problem.
Occasionally, MUSHClient will reject my zchat-login attempt, for unknown reasons. It appears that the reject happens early, sometime before the perl-code in my MUSHClient-plugin is called to authorize the connection. In an attempt to debug this behaviour, I wrote a small Java-app that attempts to connect to MUSHClient repeatedly using the exact same login-data, and outputting the results to the console. The exact same login can be accepted, then rejected, then accepted again, in three separate login-attempts happening after eachother.
Each login consists of my Java-app connecting to the MUSHClient chat-socket, waiting for 100ms, then sending the string 'ZCHAT:myUser\t\n111.111.111.11104050', then waiting for the first byte to check if it's a 'Y' or a 'N', then closing the socket and waiting for another 1000ms before retrying. The delays seem irrelevant, 1ms or 1000ms, the denials still occur.
On MUSHClient's end, the perl-code handling the connection looks like this:
# MUSHclient has received a connection from IP,name
# Return TRUE to accept it, FALSE to reject it
sub OnPluginChatAccept {
my ($tempstring) = @_;
$tempstring =~ /(.*?),(.*)/;
my $username = $2;
if ($username eq "myUser") {
echo("accepted");
return 1;
} else {
echo("rejected");
return 0;
}
}
..and this code prints 'accepted' to my MUSHClient-window every time a connection is accepted, but strangely enough, never 'rejected', which leads me to believe that the connection is rejected earlier, for some reason.'
The Java-code I use can be provided too, but it's not nearly as short as the Perl-code.
I'm using MUSHClient 3.42, on Windows XP. | | Top |
|
| Posted by
| j0nas
(56 posts) Bio
|
| Date
| Reply #1 on Fri 02 Apr 2004 10:23 PM (UTC) |
| Message
| Seems the forum didn't like my tab-indented perl-code, sorry about that. Here's a prettier version:
# MUSHclient has received a connection from IP,name
# Return TRUE to accept it, FALSE to reject it
sub OnPluginChatAccept {
my ($tempstring) = @_;
$tempstring =~ /(.*?),(.*)/;
my $username = $2;
if ($username eq "myUser") {
echo("accepted");
return 1;
} else {
echo("rejected");
return 0;
}
} | | Top |
|
| Posted by
| j0nas
(56 posts) Bio
|
| Date
| Reply #2 on Fri 02 Apr 2004 10:25 PM (UTC) |
| Message
| I'm not very clever today. Let's try using the appropriate forum-codes.
# MUSHclient has received a connection from IP,name
# Return TRUE to accept it, FALSE to reject it
sub OnPluginChatAccept {
my ($tempstring) = @_;
$tempstring =~ /(.*?),(.*)/;
my $username = $2;
if ($username eq "myUser") {
echo("accepted");
return 1;
} else {
echo("rejected");
return 0;
}
}
| | Top |
|
| Posted by
| j0nas
(56 posts) Bio
|
| Date
| Reply #3 on Fri 02 Apr 2004 10:48 PM (UTC) |
| Message
| | I just realized it might save us all some trouble if I tried installing the latest version of MUSHClient, so I installed 3.45 and tried the same thing. The exact same problem cropped up, nothing changed. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
| Date
| Reply #4 on Fri 02 Apr 2004 11:51 PM (UTC) |
| Message
| Looking at the source code for chat negotiation, the incoming call will be rejected if (in this order):
- The incoming packet size is less than 7 bytes long
- The incoming packet does not begin with "CHAT:" or "ZCHAT:"
- The session is rejected by the plugin callback "OnPluginChatAccept".
- If you have the option set "validate incoming calls" and you click "No" to the dialog box that appears, asking if you want to accept that user.
Otherwise, "YES:(chat name)\n" is sent.
Judging by what you say, the plugin is not the problem, and the 4th point is not the problem either.
What *might* be happening is that TCP/IP is breaking packets up so that the incoming packet is not 7 bytes long. eg. you might be getting:
packet 1: ZCH
packet 2: AT:
That might do it. I suggest a packet-level watcher to see if that is the case.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| j0nas
(56 posts) Bio
|
| Date
| Reply #5 on Sat 03 Apr 2004 08:28 AM (UTC) |
| Message
| | That did the trick, sometimes my Java-app sent the login-string in several smaller packets, so once I made it send it all in one string, it started working perfectly. Thanks. | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
16,503 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top