There was a need for a software for doing basic chat for computers on a network(LAN).
I have basic knowledge with Visual basic, making applicatins handle databases, files etc....
Using this I made a software where users on the particular network would log-in to chat and send files to one another.
To make the software run, I shared an amount of space on the the server, where all users have read/write permisions.
I placed my database file here. The software is able to understand each other by sharing data sent from each of them to this common space.
I have developed it with some other features where each user can detect users who might have unexpectedly left the network without properly signing out, the sending of files etc....
The prototype works just fine and serves its purpose. What i want to know is this the right way to solve the problem? When i browse i find chat programs with server/client technologies........If i am right, it seems tht this server program should be always running for the project to work? Compared to what I have created its just one program tht will not need any other program to guide it whatsoever.
I would like your comments on all this.
Your comments plz.
Your comments plz.
imagination is once limit......
You already have a server that is always running, you've used existing software and communication protocols to implement it. That server is the computer + software that contains and provides access to the database file and the protocols are whatever file-sharing mechanism your network uses. Of course, that means you're dependant on the existing stuff to always meet your requirements, but if it does, then there shouldn't be any problem.
Hi,
I have done something very similar to this in the past (using VB) - if I can dig out the source sometime I'll post it. There are a few ways to implement the software and you have found one of them. There are, however, advantages to the client/server approach which can be handled in one of 2 ways:
1) Have a single server, as you suggest, listening on a known port at a known IP (or have each client scan the local network for a response from the server). In this approach, once the server accepts a connection, it changes the port number so that other clients may request a connection on the same known port.
In this approach, each client communicates via the server, so the server becomes a bottleneck for traffic - if you want to pass a file to another client, it has to go to the server and then on to that other client.
2) Similar to the above approach, but the server just contains a list of clients. If you want to communicate with another client, the server allows you to obtain connection details. If you are using windows sockets, this means that each client needs a listening socket and an outgoing socket. This system is known as peer-to-peer and is generally accepted as being a better system. Once you have connected to all clients, the server is no longer needed for that session.
3) A system where there is no server at all - each client again has a listening and outgoing socket. When a client starts, it scans the network for other clients. Here, you can do one of two things - either each client contains a list of all other clients, making the scan a lot faster, or there is no list of local clients and you just have to wait for the scan complete - not a problem if you only have 5 computers on your local network, but a pain if you have 500!
Overall, I much prefer the client/server approach to polling a database for messages. With the client/server system your program will use less CPU time and you can use interrupts to obtain data.
HTH,
Adam
I have done something very similar to this in the past (using VB) - if I can dig out the source sometime I'll post it. There are a few ways to implement the software and you have found one of them. There are, however, advantages to the client/server approach which can be handled in one of 2 ways:
1) Have a single server, as you suggest, listening on a known port at a known IP (or have each client scan the local network for a response from the server). In this approach, once the server accepts a connection, it changes the port number so that other clients may request a connection on the same known port.
In this approach, each client communicates via the server, so the server becomes a bottleneck for traffic - if you want to pass a file to another client, it has to go to the server and then on to that other client.
2) Similar to the above approach, but the server just contains a list of clients. If you want to communicate with another client, the server allows you to obtain connection details. If you are using windows sockets, this means that each client needs a listening socket and an outgoing socket. This system is known as peer-to-peer and is generally accepted as being a better system. Once you have connected to all clients, the server is no longer needed for that session.
3) A system where there is no server at all - each client again has a listening and outgoing socket. When a client starts, it scans the network for other clients. Here, you can do one of two things - either each client contains a list of all other clients, making the scan a lot faster, or there is no list of local clients and you just have to wait for the scan complete - not a problem if you only have 5 computers on your local network, but a pain if you have 500!
Overall, I much prefer the client/server approach to polling a database for messages. With the client/server system your program will use less CPU time and you can use interrupts to obtain data.
HTH,
Adam
Re:
Thanks for all the personal comments, I have pasted them above without the names of the sender.I am in for anything new . I dont quite understand your approach but I would agree with CPF in calling it Interesting. I would be very happy to use the application, any chances of that?
Keep the following in mind while developing it:
Should work everywhere with minimal changes to the network
Easy to set-up and work with
The client that you would use to chat should be very much like the existing IM programs, If you go far from them and don't come up with something really good no one would use it.
Fast and Secured
Keep us informed.
--------
Re: Your comments plz.
--------------------------------------------------------------------------------
Isn't this the way many web-based (e.g. PHP) chat programmes work? They don't work in the traditional way of sending packets to a server and the server sending it out, but just treat the server as a log of all activity and then read from that log to find out what is happening.
That is, unless I've understood what you're saying...
------------
@sender2: if PHP works like tht, then yes it seems a lot similar.
@sender1: It works a lot like normal IMs, only tht so far I have made it a general chat, no facility to chat with individual users, can be implemented, matter of time.
About the part of setting it up, i seem to have a problem. Because as I said the app works on a common memory space tht is accessable to all.
So depending on the network, i have set a static path in the application, and then created the executable.
So in case I have to set it up on a new network, This is what i did.
-Create a common memory space
-Burn it(path) into the application and compile.
-Give the executable to all on the network.
This is how i do it manually, i have tried on 3 different networks, like my college, home and a shop.
Works fine, but since it was built, as and when I got the idea, it can be made much more efficent. Its a working prototype at the moment.
imagination is once limit......
-
Kevin McGuire
- Member
- Posts: 843
- Joined: Tue Nov 09, 2004 12:00 am
- Location: United States
- Contact:
chat program local lan
If the chat program is going to be for people on the same IP network. Such that using 255.255.255.0 as a net mask will produce a.b.c.0 with a.b.c being the same for everyone then you would be much better off using UDP broadcasts. It is _very_ easy to implement UDP/IP support using Visual Basic.
(yourIpAddress&yourNetmask)|(~yourNetmask) = chatIpAddress
Then choose a port that everyone uses and use the UDP address and everyone can talk to each other.
If some people reside on a different IP network you could implement a scheme of probing some adjacent networks with UDP packets and check for replies and once found update all other people on your network.
It would also remove the SMB share dependency, and make the program much easier to port to other operating systems and have better performance possibly.
(yourIpAddress&yourNetmask)|(~yourNetmask) = chatIpAddress
Then choose a port that everyone uses and use the UDP address and everyone can talk to each other.
If some people reside on a different IP network you could implement a scheme of probing some adjacent networks with UDP packets and check for replies and once found update all other people on your network.
It would also remove the SMB share dependency, and make the program much easier to port to other operating systems and have better performance possibly.