[ajr1234]

For some reason I'm really enjoying this conversation lol.

A variety of applications use custom ports. Skype uses 443/80 (HTTP yes) as well as other custom ones, depending on the settings. AIM uses 5190. VMWare uses 902. WoW uses 3724. RTSP video 554. Steam switches off between 3478, 4380, 4379, 4380, 27000-27050. Email clients use numerous different ones. There's no reason pawn scripts shouldn't reserve a port for themselves as well. While you can easily stuff everything through the HTTP port and sort out the request, I prefer to use the SM socket extension along with a custom listen port on the server, but that's just me. If I ever wanted to expand on that simple !call script by, say, implementing more commands, a two-way chat system, single command responses, etc., my script base would be more easily expandable/scalable. I'm only thinking ahead-- it doesn't mean that I will ever end up adding those features. There have been numerous instances where I used sockets only to find out that I never needed them. Yet, there have been instances where I was glad to have used them. So yes, sockets may end up being "pointless and redundant," but may end up being beneficial as well. Anyhow, let's just move on. Who cares. I have a pharmacology and pathology exam this week and next week, respectively. Got to study.

Thanks for the debate. I enjoyed it! The end result... well, you guys certainly have a point. For this application, just using a HTTP request is indeed way simpler. If this application tends to grow... Then my idea may be better. Still, the part where I suggested that a single DB should be stored on the web server to avoid the need to set up replication doesn't change :p

Off topic, but Dr. McKay, are you a physician in real life? I'm in medical school currently, and I have a question I'd really appreciate help with if you have time later ^^

[Dr. McKay]

Originally Posted by ajr1234 Off topic, but Dr. McKay, are you a physician in real life? I'm in medical school currently, and I have a question I'd really appreciate help with if you have time later ^^

Nope. This is where the name comes from.

[Impact123]

I really don't understand why you point in the direction of sockets.
SourceMod provides an api for dbi, why wouldn'nt you consider to use this?.

Yours sincerely
Impact

[Doc-Holiday]

Originally Posted by Dr. McKay Nope. This is where the name comes from.

only the most bad ass stargate series there was... pissed the movie never came out though....

[ajr1234]

Originally Posted by Dr. McKay Nope. This is where the name comes from.

Oh, I see. Haven't seen the series, but tempted to now.

Originally Posted by Impact123 I really don't understand why you point in the direction of sockets. SourceMod provides an api for dbi, why wouldn'nt you consider to use this?. Yours sincerely Impact

To avoid replication issues with multiple physical servers. The debate was about whether to use a custom port and listener or to just use a simple http request with sockets.

[Doodil]

Originally Posted by ajr1234 To avoid replication issues with multiple physical servers. The debate was about whether to use a custom port and listener or to just use a simple http request with sockets.

Thing is, if you use the database-interface of SourcePawn to directly connect the plugin on all of your gameservers to a single database, you won't have replication issues and you don't need sockets/http requests. There is no need to first call the webserver, which then calls the database and stores the information, when you can store the information directly from within the plugin.

For some reason it seems to me that you believe that every instance of a plugin can only store data in it's own database... which is not the case.

[ajr1234]

No lol, that is not what I said. I am well aware that Pawn plugins can access other databases. I've made more than a dozen private plugins for money, so I believe I have a firm grasp on how the system works.

Summary:

Pawn plugins (multiple game servers) -> Send data to web server -> web server stores it in central database -> Database accessible on website

The reason I suggest sockets is to avoid the need to set up remote querying on the SQL database (if the gameservers are on a different machine than the web server) and to keep DB management centralized (i.e. avoid managing the database on both Pawn and the website).

[Doc-Holiday]

Originally Posted by ajr1234 No lol, that is not what I said. I am well aware that Pawn plugins can access other databases. I've made more than a dozen private plugins for money, so I believe I have a firm grasp on how the system works. Summary: The reason I suggest sockets is to avoid the need to set up remote querying on the SQL database (if the gameservers are on a different machine than the web server) and to keep DB management centralized (i.e. avoid managing the database on both Pawn and the website).

I had something similar to this where s player could apply to the community and register a forum account from the game by typing a command with parameters.

I just queried the sql db from sm and updated the tables.

Then PHP to simply grab the info and sorry it via time stamp in an html table (custom vbulletin page)