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
➜ Plugins
➜ Any way to make a 'chat' plugin?
|
Any way to make a 'chat' plugin?
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2
3
4
5
6 7
| Posted by
| Poromenos
Greece (1,037 posts) Bio
|
| Date
| Reply #75 on Fri 11 Apr 2003 06:28 AM (UTC) |
| Message
| | Hmm, sounds to me like the MudMaster protocol sucks... I haven't followed the entire thread, so I'm talking out of my behind, but that's the idea I got... Would it be possible to make your own protocol, and only make it compatible with MudMaster? I.e. it would probe the client/server when it connected, and it would switch protocols accordingly... Of course, this may not be needed, if you feel that mudmaster is OK... Just an idea... |
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it! | | Top |
|
| Posted by
| Skarsnik
(11 posts) Bio
|
| Date
| Reply #76 on Fri 11 Apr 2003 06:46 AM (UTC) |
| Message
| > Hmm, sounds to me like the MudMaster protocol sucks... I haven't followed the entire thread, so I'm talking out of my behind, but that's the idea I got... Would it be possible to make your own protocol, and only make it compatible with MudMaster? I.e. it would probe the client/server when it connected, and it would switch protocols accordingly... Of course, this may not be needed, if you feel that mudmaster is OK... Just an idea...
Yeah, develop your own chat, then make also add MudMaster and zChat chat protocol aswell.
And then (THIS IS THE GOOD BIT) the next person who writes a chat application will have to support all three and their new one!
Skars
| | Top |
|
| Posted by
| Skarsnik
(11 posts) Bio
|
| Date
| Reply #77 on Fri 11 Apr 2003 06:59 AM (UTC) |
| Message
| > I am having trouble testing zChat - for one thing I can't work out how to change the port number from 4050, and for another it keeps crashing with an access violation. Does anyone else have better luck them that with zChat?
I have the similar issues with zChat, which is one of the reasons I wrote a mm compatible chat (and let zChat can resolve its own issues).
> It seems to me there are 2 IP addresses - the "reported" one from the client, which might be a private address, eg. 10.0.0.1, and the "actual" address which the client connected from, which might actually be the NAT router or somesuch.
MM GUI has a simple approach to this, if the machine has more than one IP it asks the user to select the appropriate IP. When you establish a connection you send your (manually selected) IP information in the handshake, (so the recieving chat application does not have to attempt to resolve the new connections IP). It does work, but I guess it could be improved.
Skars
N.B. These questions might have previously been answered, I avioded the essay messages. | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #78 on Fri 11 Apr 2003 07:23 AM (UTC) Amended on Fri 11 Apr 2003 07:28 AM (UTC) by Shadowfyr
|
| Message
| > And then (THIS IS THE GOOD BIT) the next person who writes a chat application will have to support all three and their
> new one!
Except that since neither MM or zChat specifically mandates that you hold commands ID numbers open for expansion, you can simply extend the command set for the one you are using. The new clients would see and respond to the new commands, but regular MM or zChat programs would likely just ignore them. It then becomes the next guys decision as to whether to support the original MM spec, what ever extensions may have already been added to MM2k or go all the way and also support yours.
This is not imho a major problem. Most of the flaws in the existing protocal are ones that could be fixed by using such an extended command to test if it is a compatible client and use the extended commands to send text with proper coloring, etc. If the client doesn't support it, then you default to the 'existing' command set that you already support as part of your own spec. Not compatibility issues would arise, since the only thing you could break is the extended set of commands you added anyway. I believe I mentioned this already in the thread actually. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #79 on Fri 11 Apr 2003 07:51 AM (UTC) |
| Message
| | This thread, which will soon take the prize as the longest one on the forum. ;-) |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Flannel
USA (1,230 posts) Bio
|
| Date
| Reply #80 on Fri 11 Apr 2003 08:01 AM (UTC) |
| Message
| I think what Poromenos was getting at was, have your own protocol, even if it was similar, and then have it figure out what kind of client it was communicating with, and then 'talk down' to that client.
That wouldnt require the next coder to make it compatible with all three, Just any one. Since this client would be able to communicate it, as if it were MM, or zChat.
Example:
User X makes a client, that is compatable with MM and zChat, then connects to a chat... bunch (web?) and eventually talks to someone on MushChat, the Mushchat will do the handshake and stuff, and see that Xclient talks like MM, so as far as MushChat is concerned, XClient is MM, and can communicate that way.
Think that made sense. |
~Flannel
Messiah of Rose
Eternity's Trials.
Clones are people two. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #81 on Fri 11 Apr 2003 08:09 AM (UTC) |
| Message
| I'm still wresting with message loops. According to the MM chat spec, for a CHAT_TEXT_EVERYBODY:
Quote:
Receiver:
If the chat connection isn't being ignored, you simply print the string. If you have any connections marked as being served you need to echo this string to those connections. Or if this is coming from a connection being served, you need to echo to all your other connections. This allows people who cannot connect directly to each other to connect with a 3rd person who can connect to both and be a server for them.
Now say you have three connections:
A -> called -> B -> called -> C -> called -> A
This is certainly possible.
Now according to the spec if A does a "chat all" then the message goes to B who sends it to C. However C does exactly the same thing, and sends it to A, who then sends it to B again, and so on.
In fact, I can reproduce that in MUSHclient with only 2 connections, A and B. If A calls B and B in turn calls A, then you do a chatall, then you need to abort the client before it runs out of memory.
I notice in the zChat they have message stamps, so you can tell when a message has been around the loop, something that is not in the MM spec.
I can work around it to an extent by remembering the last message sent, and decline to send the same message twice in a row. However this then has the problem that you can't send the same message twice legitimately. For instance, you might be telling someone which way to walk, and saying "north" twice might be part of the directions.
Can anyone think of a better way, but still working within the MM chat specs?
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| NightCrawler
Canada (16 posts) Bio
|
| Date
| Reply #82 on Fri 11 Apr 2003 01:08 PM (UTC) |
| Message
| I was just looking at the message regarding potential "loops" in the conversation. Specifically, where Nick has indicated that if A calls B and B calls A.
This doesn't actually happen in MM. If you attempt to call a connection that you've already established a session with, MM sends you a message letting you know you're already connected to that client. It won't establish a second connection to the same client.
The only exception would be on a network. I could call a client using it's public address and then call it again using it's private address and establish two connections to the same session. MM has no way of knowing that they're actually the same computer since the IPs (and MACs) are different.
Regarding Zchat, I've played with it a few times but could never find a way to change the port number either. Perhaps that feature is only available if it's used in conjunction with a registered version of Zmud.
As for the Access Violations in Zchat/Zmud, I'm going to hazard a guess that you're using it on an NT-based system (Win2k, XP). Zchat apparently tries to access a protected system file (or files) or memory address range for some reason and returns this error when the operating systems says, "Hands off!" The person who wrote Zchat is aware of the problem, but doesn't seem to be too interested in fixing it. His loss, I suppose. Perhaps he'll regret his thinking when his customers start switching to MM and MushClient :) |
A computer once beat me at chess, but it was no match for me at kick-boxing... | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #83 on Fri 11 Apr 2003 08:51 PM (UTC) Amended on Fri 11 Apr 2003 08:52 PM (UTC) by Shadowfyr
|
| Message
| > I was just looking at the message regarding potential "loops" in the conversation. Specifically, where Nick has
> indicated that if A calls B and B calls A.
>
> This doesn't actually happen in MM. If you attempt to call a connection that you've already established a session with,
> MM sends you a message letting you know you're already connected to that client. It won't establish a second
> connection to the same client.
Which is irrelevant, since the problem is when a third client connects to the first one. I read somewhere something about how such loops can and do happen and it represents one of the 'major' flaws in the design. A good one would pass the IP of the originator in the packet 'and' a time stamp, just like TCP/IP does and the various clients involved would simply ignore those with the same stamp. Neither MM nor zChat effectively deal with this. Extentding the protocal so that Mushclients version could identify each other and use a seperate set of commands to talk to one another that includes such an ID is imho the only way to really fix it. However, that only fixes it for the Mushclient users, but it is the best that can be managed until the MM2k people or Zugg impliments a similar 'fix' in zChat.
MM and zChat are both buggy 'period'. Extending one of the protocals with special 'working' versions of the command set of one of them would solve all these problems and still allow the basic protocal to work.
Going back a few more messages... Yes Flannel, I get what you mean, but my point is that it is a 'bad' solution to make a completely new protocal like zChat did and then 'support' the old one. Instead you allow the commands 1-31 that 'are' part of the MM protocal to work as normal, but then add commands like 100, 101, 102, etc. that implement the fixes and extended capabilities. This is how you provide real compatibility 'and' also fix the problem. When a copy of Mushclient connects to something it would start with the normal MM or zChat request, then when established it would d something like <100><Muclient?><chr 255> and the other one 'if' it was MM or zChat would ignore the command. If it was Muclient compatible, then it would return <100><Yes><chr 255>, at which point they talk to each other using the 'fixed' command set in the 201-231 range. The next guy to make a client doesn't need to worry about supporting the extended set if they are satisfied with what the normal MM set can do, but yes, to be fully compatible, they would need to add the extensions as well.
> The person who wrote Zchat is aware of the problem, but doesn't seem to be too interested in fixing it.
This seems to be a common theme with Zugg. lol
| | Top |
|
| Posted by
| Skarsnik
(11 posts) Bio
|
| Date
| Reply #84 on Sat 12 Apr 2003 03:27 AM (UTC) |
| Message
| > When a copy of Mushclient connects to something it would start with the normal MM or zChat request, then when established it would d something like <100><Muclient?><chr 255> and the other one 'if' it was MM or zChat would ignore the command.
Im all for extending the protocol, but...
There is already a command in the spec to identify the chat application that is sent immediatly after the handshake by both zChat and MudMaster.
e.g. <19>MUSHchat 1.1.0<255>
> I notice in the zChat they have message stamps, so you can tell when a message has been around the loop, something that is not in the MM spec.
I think this has been covered but, zChats message stamps only provide the callers unique ID, which will NOT totally solve the problem (as you can still get echos because someone is served by two people your chatting to ect...).
The only work around that I can think of that will totally solve any echo/terminal loop problems would be to provide a Unique (randomly generated) ID for each *message*. Each client would then need to store a list of reciently recieve message ID's and as soon as it gets a repeat it will not display the message or pass the message on again if its serving someone).
This wouldn't be as bad as it sounds as the client would really only need to store the UID's of the last 20 or so messages...
Once again I personally think if your commited to the basic basic protocol this should come first, and then think of how to improve it.
Skars
| | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #85 on Sat 12 Apr 2003 07:18 AM (UTC) |
| Message
| Yes, I am using NT, and I would think a few others are as well, as NT now embraces Windows 2000, XP etc.
I want to work within the existing protocol initially, although I see that my spec must be a bit out of date, as it doesn't mention a 4-digit number that appears at the start of peeked text.
I seem to have solved the loop problem for now, by remembering the last message *sent*, and then discarding that message if it is *received* again in the next 10 seconds.
Hopefully in many cases people won't have loops anyway, however I can certainly conceive of how they could be set up, especially if you "request connections".
Testing seems to be going well, a bit more work needed on doing a scripting interface, and then it will be ready for a user test.
Will many people here be interested in:
* snooping other connections?
* transferring files?
* sending commands?
I also see a potential problem with the colouring of messages, but perhaps will let that come out in the testing *evilgrin*.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #86 on Sat 12 Apr 2003 06:27 PM (UTC) Amended on Sat 12 Apr 2003 06:29 PM (UTC) by Shadowfyr
|
| Message
| > > When a copy of Mushclient connects to something it would start with the normal MM or zChat request, then when
> > established it would d something like <100><Muclient?><chr 255> and the other one 'if' it was MM or zChat would
> > ignore the command.
> Im all for extending the protocol, but... There is already a command in the spec to identify the chat application that
> is sent immediatly after the handshake by both zChat and MudMaster.
> e.g. <19>MUSHchat 1.1.0<255>
Only one problem... If this was a true 'extension' of an existing protocal, then the existing MM or zChat clients, that you used as a 'base' for the extended version, would be looking for a version ID that was like "<19>MudMaster 1.1<255>" or "<19><9>zChat 1.1". Existing clients would not therefore correctly recognize any version you gave them with MUSHchat in it as valid, which is why imho it would be better to use a seperate request. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #87 on Sat 12 Apr 2003 09:18 PM (UTC) |
| Message
| The method of detecting the different protocols is AFIK the initial negotiation, where you either get CHAT: or ZCHAT: as the very first character sequence received.
The actual version is just for information and the first few characters could conceivably be used to detect which client is actually in use.
However I don't think this talk of extending the protocol really solves the problem of message loops, especially where it is likely to be in a mixed client environment. For instance, if MUSHclient has to send a message to MudMaster, then it must use the existing protocol, and conceivably a loop of MUDMaster clients might exist. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #88 on Sat 12 Apr 2003 11:46 PM (UTC) |
| Message
| | True, but not extending it doesn't fix it either. In the short term I agree that it is best to use the un-extended version, but it would be nice to make it more stable and less buggy when everyone connected is a Mushclient user later on. | | Top |
|
| Posted by
| Skarsnik
(11 posts) Bio
|
| Date
| Reply #89 on Sun 13 Apr 2003 04:40 AM (UTC) |
| Message
| > Only one problem... If this was a true 'extension' of an existing protocal, then the existing MM or zChat clients, that you used as a 'base' for the extended version, would be looking for a version ID that was like "<19>MudMaster 1.1<255>" or "<19><9>zChat 1.1". Existing clients would not therefore correctly recognize any version you gave them with MUSHchat in it as valid, which is why imho it would be better to use a seperate request.
MudMaster MudMaster2000 and zChat (at least the version I have) does not use the <19> information appart for display purposes.
> However I don't think this talk of extending the protocol really solves the problem of message loops, especially where it is likely to be in a mixed client environment. For instance, if MUSHclient has to send a message to MudMaster, then it must use the existing protocol, and conceivably a loop of MUDMaster clients might exist.
Nick they wont let you re-write zChat and MudMaster, you could ask, but im pretty sure you will be ignored :()
Skars
| | 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.
277,035 views.
This is page 6, subject is 7 pages long: ![[Previous page]](/images/thin_prev.gif)
1
2
3
4
5
6 7
![[Next page]](/images/thin_next.gif)
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top