7 replies to this topic

[ArekBulski]

I was thinking about my incoming IM project, Gaduzila 2.0, and I was wondering...

Can I use MySql connection to connect IM client with the server? MSN, Skype and so on, are all using TCP/IP connections I believe, but using SQL would be much easier for me.

Does this approach have any drawbacks? Maybe scalability, security or I don't know. Anyone having knowledge please share with me. Any comment at all will be helpful, actually.

[debtboy]

Please explain more, I don't understand.
SQL server uses TCP/IP unless your using named pipes??

Is there a database involved with the application??
More info please...

[ArekBulski]

I am planning to build a messenger, like MSN for example. Those usually use TCP/IP connections to connect to the server. Now, I was thinking about using MySql server as a central, and MySql connections from clients to connect with it.

Sql connections are based on TCP/IP, yes. I do not want to use TCP/IP streams directly. Inventing my own protocol similar to MSN's would be a nightmare.

This approach must have some drawbacks, but I think it would also make the protocol simple and easy to make. Unless I am wrong, hm. Sorry, I was too tired to write with more sense.

[debtboy]

OK, I think I'm starting to get it.

Will be using persistent direct connections to MySQL
or Web Service based??

Your client is probably rather thin,
just sending and receiving data,
a dataadapter, dataset, and a few queries
unless you add lots of features.

Will you be parsing the datasets manually
or dumping them into a data sourced object.

As for protocol, how about SOAP over TCP/IP??


More info please...

[debtboy]

I made the assumption that there can be multiple
people on "the channel" for lack of a better phrase.
So as I understand it, it's not a one to one connection.

ArekBulski, can there be more than 2 people on "the channel"?

[ArekBulski]

Thank you guys, your questions are very intriguing. I will try to answer them however I can.

debtboy- I was thinking about using direct connections with a MySql database. This way I would not need any (complex) server application. Only a database, some privilege configuration and I'm set up. In the worst case scenario, I could implement a server application that takes records from one table, process and validate it, and put it into another table.

What is a Web Service exactly? An HTTP or TCP server, with a database backend? What is SOAP over TCP? What means "Will you be parsing the datasets manually or dumping them into a data sourced object."? I have no experience with databases whatsoever.

Jordan- I think all messengers like MSN Skype and so on are using centralized connectivity. For what reason I cannot tell. Maybe to have ability to spy onto users, spam them with advertising and ban those who abuse the network.

Decentralized authentication would be an interesting idea, doable with the use of cryptography and certificates. But decentralized connectivity... yare yare... some poeple cannot open ports or have changing IPs. Thistle has such a thing, writing Gaduzila 1.0 with TCP streams was a nightmare.

debtboy- You have a nice idea there. I was thinking about it, too. I would like to have an ability to send messages to everyone on my contact list at once. Or to group contacts and make conferences. So answer is definitely yes.

[debtboy]

What is a Web Service exactly? An HTTP or TCP server, with a database backend? What is SOAP over TCP? What means "Will you be parsing the datasets manually or dumping them into a data sourced object."? I have no experience with databases whatsoever.

Hi ArekBulski,
This link explains a web service better than I could:
Web service - Wikipedia, the free encyclopedia

Web Services give you unlimited flexibility to execute any control code you like between the request and the destination.
It can handle authenticating to the server, receiving data, sending data, interacting with a database, etc..., etc...

I've written many at work to control accessing and querying databases as well as delivering datasets to user's applications. They are web based, which makes them very good for executing code subject to change. Keep your client apps very thin and you can just update the web service(s) without having to roll out new client apps.

For example, you start your client up which sends a status message to the Web Service (status module, (web services can have many modules)) it stores your online status in database and extracts the online status of other users and passes that via SOAP over TCP/IP as an XML dataset to your client.
Your client parses the dataset (strips off the XML tags) and displays online status of other users in your client.

Now you pick 2 clients and send a message. Your client sends the user IDs of the 2 selected clients and the message to the Web Service (message module).
The Web Service stores the message and recipients in the database.
Recipient 1's synchronous request comes into Web Service (update module)
which in turn extracts the message and passes it to the recipient 1's client which parses and displays it.

Ditto for recipient 2

It sounds much worse than it is, the code is very simple and the best part...
It's stateless and relatively secure as you will receive no data that wasn't requested.

(this is how I understood your project)

As for no experience w/ databases, .NET makes it easy
You define the following data objects as SQL ODBC or other native type:
Connection
InsertCommand
SelectCommand
UpdateCommand
DeletCommand
CommandBuilder
DataAdapter
Dataset

assign DB connect text to the ConnectionString argument fo the connection object
assign a text query to the CommandText argument of the Command object
assign a the Command to a DataAdapter
assign a Connection to a DataAdapter
Fill a dataset w/ results from dataAdapter

You know how it works, if not I can give you examples.