20 replies to this topic

[Snarg]

YaC-P Beta 1.0

Hello and welcome to YaC-P (Yet Another Chat Program), pronouced 'Yack Pee'. Although there is a veritable cornucopia of chat programs already availiable, I felt this would be a good project for me to learn more about AutoIt and TCP. It has been an excellent, although mostly frustrating, journey and there seems to be no end in sight.

YaC-P is a direct descendant of erifash's AU3 Chat program.

Some features of YaC-P:

• Unlimited number of users
• Logging of all type of server events
• Logging of all chat events
• Remote Admin login
• Kick a user from the Admin client
• Ban a user from the Admin client
• Environment settings stored on the server and sent to the client
• A seksi GUI :)

Features yet to be added:

• PM's popup in a seperate window
• File transfer
• Keep more settings on the server, not the client
• Secure, to the best of my ability, the client/server connection
• Remote admin login Done!
• Display user name in color on user list
• Ability to minimize client to the system tray
• Scale the client GUI based upon the max number of connections allowed
• Un-ugly the code. Although I wish it were true, I have never been accused of writing 'elegant' code. I would love to be able to do this someday and will take any help I can get
• A full accounting of credit given where credit is due. I have snagged more then my fair share of code from this forum and would like to give credit to those who deserve it. If you recognize some of your code please, let me know
• A sexy GUI Done!

Known bugs:

• One warning is generated when beta compiling the client. The client still runs fine, but this is annoying
• Client/server communication is *NOT* secure. It is probably possible for someone to 'spoof' the server
• Sometimes the client list is not passed to a newly connecting client. I have only done testing on my local loopback. As this only happens when many clients are connected, I suspect the problem may be TCP events firing to quickly for the client/server to keep up
• Variables/functions follow no type of naming convention since I have never been taught one. Any good pointers out there...?

I can't think of anything else off of the top of my head. If you do run accross any errors please let me know. Be as specific as possible and I will do my best to fix it.

There should be no reason this will not work over the Internet. Ensure you have forwarded whatever port you selected to use. Consult the documentation for your router/firewall to find out how to forward ports. Also, ensure your users are connecting to the correct IP/port.

Changelog - Beta 1.0

• Removed the server GUI. I am hoping this will help speed up the server.
• Added a configuration .ini file to the server.
• Added an Admin client.
• Made the Admin client and User client look good.
• Changed how the client GUI's were built and displayed.

So, without further adieu, here is the program:
Previous number of downloads: 42

Attached Files

•  YaC_P.zip   297.95K   893 downloads

Edited by Snarg, 06 December 2006 - 09:18 AM.

[Mosquitos]

Great script but you can not see the users in the client.
On the server you can see the users that login.

[Apzo]

Great job, Snarg

I tried something based on Erifash's scripts too but I couldn't have file transfer working easily.


Two things I have in mind, that makes a difference between a good script and a useful script :

Functions and GUI should always be separated.
If I want to use chat abilities between two of my scripts, I would just have to pick the functions I need.
For example here I have to wipe all of the GUI code.
The model "include file + example file" is an excellent way to do this.

Why do coders hate .ini files ?
Things like IP port, max connections, listening address, packet size, etc etc should be read from a .ini file (or whatever). So you don't have to retype them, and launch a server or client with no questions.
For complex projects with dozens of scripts, one setting should be defined once and only once, and readable by any other script. .ini files are realy easy to use with AutoIt.


That said, I'm growing impatient to see how you project evolves
For file transfer, do you plan to use a p2p model, or will the server act as a proxy ?

Apzo.

[Manadar]

Not a bad first try at all. You should spend more time on the protocol between the server and client. The protocol is thé most important thing of a chat client. In general, the protocol can make or break your program.

Keep in mind that once your project gets bigger, it is harder to stop things from lagging, so you should try to keep your server as small and simple as possible, while still providing a lot of functionality.
Personally, I don't think it is a good idea to create a GUI for a server, instead, use a ini file to read some options into the server and create a seperate editor. To manage your server, create a different client (or integrate this client into the main client) that has extra features to manage your server.

I would also like to know how you plan on doing FileTransfer, it is more secure if you would use the server as a proxy, but it is also significantly slower. I am in doubt with this myself, although I plan on using the server as a proxy and a temporary (1 or 2 days) server, where you can download the files from for extra functionality.

It should also be noted, that as an end-user you don't want to have to fill in a lot of technical details before you can start using it. MSN Messenger or Windows Live Messenger are good examples of a easy-to-use chat clients. Pick a default port for your server (look up on the web which one is not taken yet), to save the user some work.

[Snarg]

Great script but you can not see the users in the client.
On the server you can see the users that login.

Open up the server script and find this function:

Func TCPSendText ($Data, $iSocket)
    ;Sends data over a TCP connection
    ;You may or may not need this delay. While testing on a local network I found I needed some type of delay.
    ;It seems that TCPSend was firing to fast for TCPRecieve to pick up. Adjust as needed.
    Sleep (15)
    Local $Buffer = ""
    $Buffer = StringLen ($Data) & "," & $Data
    TCPSend ($iSocket, $Buffer)
EndFunc ;==>TCPSendText

Functions and GUI should always be separated

Are you saying I should not have function calls in the GUI loop? Instead the GUI should be on-event based...?

Why do coders hate .ini files ?
Things like IP port, max connections, listening address, packet size, etc etc should be read from a .ini file (or whatever). So you don't have to retype them, and launch a server or client with no questions.
For complex projects with dozens of scripts, one setting should be defined once and only once, and readable by any other script. .ini files are realy easy to use with AutoIt.

I have no problem with .ini files, I was just trying to do something different :) I can have the server write the settings the admin chooses to an .ini file so he does not have to redo the settings every time he shuts down the server. I am trying to avoid static settings on the client side to keep the connection as secure as possible. For example: If $CommandText on the client side were in a static .ini file, or even kept in the code it's self, it would be much easier for someone to spoof the server. It can still be done however I think I have added a degree of difficulty.

That said, I'm growing impatient to see how you project evolves :)

So am I :)

For file transfer, do you plan to use a p2p model, or will the server act as a proxy ?

I'm thinking of a combination of the two. Client A will send a file transfer request via the server to Client B. Once Client B acknowledges the request, the server will drop out of the loop and it will become a P2P connection.

Not a bad first try at all. You should spend more time on the protocol between the server and client. The protocol is thé most important thing of a chat client. In general, the protocol can make or break your program.

Thanks for the input. I have tried my best and would love to hear your thoughts on how I can make it better.

Keep in mind that once your project gets bigger, it is harder to stop things from lagging, so you should try to keep your server as small and simple as possible, while still providing a lot of functionality.

I have tried to keep the main loop as tight as possible with a minimum of function calls. I'll see if I can make it smaller.

Personally, I don't think it is a good idea to create a GUI for a server, instead, use a ini file to read some options into the server and create a seperate editor. To manage your server, create a different client (or integrate this client into the main client) that has extra features to manage your server.

Not a bad idea. I tried to build it with the lowest common denominator in mind. I know many people like shiny buttons. I do think the next step is to move to a seperate admin client to reduce server overhead.

I would also like to know how you plan on doing FileTransfer, it is more secure if you would use the server as a proxy, but it is also significantly slower. I am in doubt with this myself, although I plan on using the server as a proxy and a temporary (1 or 2 days) server, where you can download the files from for extra functionality.

See above.

It should also be noted, that as an end-user you don't want to have to fill in a lot of technical details before you can start using it.

I agree. I was thinking, when I set it up this way, of a client having the ability to connect to multiple servers. To do that you would either need to build a list that is distributed with every client (and have a way to update that list every time a new server comes on-line) or have the user face the technical difficulties of putting in an IP and port number.

[erifash]

Wow, I can't wait to see how this turns out!

AU3Chat was a good start for me but I don't think I was ready for that kind of project commitment. I guess it was a combination of laziness, school, and my affinity for sleep that put me behind. I'm just good at writing small scripts. Oh well.

I'm very glad that others are being inspired by my work, though! Keep it up!

[Manadar]

I agree. I was thinking, when I set it up this way, of a client having the ability to connect to multiple servers. To do that you would either need to build a list that is distributed with every client (and have a way to update that list every time a new server comes on-line) or have the user face the technical difficulties of putting in an IP and port number.

Or you should set up a main server, that holds a list of other servers that manage the actual chatting traffic. So the client first connects to the main server, gets a list, and then asks the user which server to connect to.

[Snarg]

Or you should set up a main server, that holds a list of other servers that manage the actual chatting traffic. So the client first connects to the main server, gets a list, and then asks the user which server to connect to.

To complicated for me right now. Lemme get this thing working the way I want first :)

[Snarg]

First post updated. I am a glutton for feedback, please let me know what you think. Thank you.

[NELyon]

This looks pretty nice.

One question: Why did you name it Yack Pee (YaC-P)?

EDIT: Nevermind. Read your sig. It told me

Edited by D-Generation X, 06 December 2006 - 09:08 PM.

[Dellairion]

(File "YaC-P Server.au3"):

Global $List[$MaxUsers][2]
Global $List[^ ERROR

Error: Array variable subscript badly formatted. ?

nvm lol :)

Edited by Dellairion, 17 December 2006 - 03:44 PM.

[Snarg]

(File "YaC-P Server.au3"):

Global $List[$MaxUsers][2]
Global $List[^ ERROR

Error: Array variable subscript badly formatted. ?

nvm lol :)

In the server.ini file, did you assighn a number for MaxUsers? Also, when complining the client with the beta version of AutoIt you will get a warning. You can safely ignore this warning.

[Dellairion]

In the server.ini file, did you assighn a number for MaxUsers? Also, when complining the client with the beta version of AutoIt you will get a warning. You can safely ignore this warning.

you should add something like:

If IniRead("server.ini", "Settings", "MaxUsers", "" ) = "" Then
    IniWrite("server.ini", "Settings", "MaxUsers", "10")
    $MaxUsers = "10"
Else
    $MaxUsers = IniRead("server.ini", "Settings", "MaxUsers", "" )
EndIf

to auto setup a basic config and to prevent the server from a crash.

Edited by Dellairion, 17 December 2006 - 03:55 PM.

[Snarg]

you should add something like:

If IniRead("server.ini", "Settings", "MaxUsers", "" ) = "" Then
    IniWrite("server.ini", "Settings", "MaxUsers", "10")
    $MaxUsers = "10"
Else
    $MaxUsers = IniRead("server.ini", "Settings", "MaxUsers", "" )
EndIf

to auto setup a basic config and to prevent the server from a crash. :)

Not a bad idea. When I get time to work on this again I will be sure to include it. How do you like it so far?

[Dellairion]

Not a bad idea. When I get time to work on this again I will be sure to include it. How do you like it so far?

better then mine lol. it's good for me

[erifash]

Here are some suggestions:

• Make the admin feature built into the client. If you log in with the username admin, it would prompt you for the password.
• Have the default IP on the client be @IPAddress1. This will make it easier to test locally.
• Try making your code more modular so parts can easily be modified without damaging functionality or creating bugs.

Keep up the good work!

[Snarg]

Here are some suggestions:
Make the admin feature built into the client. If you log in with the username admin, it would prompt you for the password.

I tried that, using the code you originaly wrote, however when the login screen was destroyed and the chat screen created, for whatever reason, SkinCrafter would not skin the new GUI. I didn't feel like chasing it down and fixing it so I took the lazy way out and created two seperate clients. One for a regular user and one for an admin.

Have the default IP on the client be @IPAddress1. This will make it easier to test locally.

Good for testing however an average user would not be able to figure out why they can not connect to the server :)

Try making your code more modular so parts can easily be modified without damaging functionality or creating bugs.

Things to do in the future...

This isn't a dead project, I just dont' have a lot of time to work on it. The biggest future plans include PM's in a seprate window and file transfer. Right now I am working on a reliable way to send connected client IP's from the server to connecting clients.

[microsoft]

Plase Update To Autoit V 3, 2, 4, 9

[Fabry]

What do this code do?

;Used by SkinCrafter
DllCall ($Dll, 'int', 'InitLicenKeys', _
        'int', _BSTR ('0'), _
        'int', _BSTR ('SKINCRAFTER'), _
        'int', _BSTR ('SKINCRAFTER.COM'), _
        'int', _BSTR ('support@skincrafter.com'), _
        'int', _BSTR ('DEMOSKINCRAFTERLICENCE'))
DllCall ($Dll, 'int', 'DefineLanguage', 'int', 0)
DllCall ($Dll, 'int', 'InitDecoration', 'int', 1)
DllCall ($Dll, 'int', 'LoadSkinFromFile', 'int', _BSTR (@TempDir & '\X-skin.skf')) ;Select the skin to use here
DllCall ($Dll, 'int', 'ApplySkin')

[Snarg]

What do this code do?

Uses the SkinCrafter .dll (included in the .zip file) to skin the GUI.