XMLSocket connections
XMLSocket connections
Hello.
He would be interesting to write a module so that he is compatible protocol IRC with object XMLSocket Actionscript.
To use the XMLSocket object, the server computer must run a daemon that understands the protocol used by the XMLSocket object. The protocol is as follows:
- XML messages are sent over a full-duplex TCP/IP stream socket connection.
- Each XML message is a complete XML document, terminated by a zero byte.
- An unlimited number of XML messages can be sent and received over a single XMLSocket connection.
The XMLSocket object is useful for client-server applications that require low latency, such as real-time chat systems. A traditional HTTP-based chat solution frequently polls the server and downloads new messages using an HTTP request. In contrast, an XMLSocket chat solution maintains an open connection to the server, which allows the server to immediately send incoming messages without a request from the client.
Example server using Ultimate ircd+Terra XML: irc.terra.es
Example chat web client using XMLSocket: http://www.terra.es/chat
nice idea?
I not to program itself in c, write this post in case somebody is animated to do it
g00d bye
He would be interesting to write a module so that he is compatible protocol IRC with object XMLSocket Actionscript.
To use the XMLSocket object, the server computer must run a daemon that understands the protocol used by the XMLSocket object. The protocol is as follows:
- XML messages are sent over a full-duplex TCP/IP stream socket connection.
- Each XML message is a complete XML document, terminated by a zero byte.
- An unlimited number of XML messages can be sent and received over a single XMLSocket connection.
The XMLSocket object is useful for client-server applications that require low latency, such as real-time chat systems. A traditional HTTP-based chat solution frequently polls the server and downloads new messages using an HTTP request. In contrast, an XMLSocket chat solution maintains an open connection to the server, which allows the server to immediately send incoming messages without a request from the client.
Example server using Ultimate ircd+Terra XML: irc.terra.es
Example chat web client using XMLSocket: http://www.terra.es/chat
nice idea?
I not to program itself in c, write this post in case somebody is animated to do it
g00d bye
I have to say i agree. What's the point of making the protocol specification public if you have to write gateway programs to make clients comply with the protocol. If you want to connect to an IRC server use an IRC client.
And as for actionscript if my memory serves me right that has something to do with either flash or shockwave apps. And there are already flash apps at least that have been written to connect to an IRC server as an IRC client and do conform to the protocol.
So this to me just sounds like you want someone else to do all the work for you.
No offence intended and i dont mean to sound rude. So sorry.
And as for actionscript if my memory serves me right that has something to do with either flash or shockwave apps. And there are already flash apps at least that have been written to connect to an IRC server as an IRC client and do conform to the protocol.
So this to me just sounds like you want someone else to do all the work for you.
No offence intended and i dont mean to sound rude. So sorry.
where is that api of actionscript?
single open this post because the power seemed to me an interesting functionality for unrealircd to accept connections of xmlsocket for write webchats using javascript or flash.
If your you think that I want that others make my work (which single it consists of changing \ r by \ 0 in which the server commands to the client) triviality goes. If us you like the idea not they carry out it…
Just as a functionality for cgi::irc exist because not to put another one for webchats that uses xmlsocket?
single open this post because the power seemed to me an interesting functionality for unrealircd to accept connections of xmlsocket for write webchats using javascript or flash.
If your you think that I want that others make my work (which single it consists of changing \ r by \ 0 in which the server commands to the client) triviality goes. If us you like the idea not they carry out it…
Just as a functionality for cgi::irc exist because not to put another one for webchats that uses xmlsocket?
Re: XMLSocket connections
Always exists!akond wrote:Hello.
He would be interesting to write a module so that he is compatible protocol IRC with object XMLSocket Actionscript.
To use the XMLSocket object, the server computer must run a daemon that understands the protocol used by the XMLSocket object. The protocol is as follows:
- XML messages are sent over a full-duplex TCP/IP stream socket connection.
- Each XML message is a complete XML document, terminated by a zero byte.
- An unlimited number of XML messages can be sent and received over a single XMLSocket connection.
The XMLSocket object is useful for client-server applications that require low latency, such as real-time chat systems. A traditional HTTP-based chat solution frequently polls the server and downloads new messages using an HTTP request. In contrast, an XMLSocket chat solution maintains an open connection to the server, which allows the server to immediately send incoming messages without a request from the client.
Example server using Ultimate ircd+Terra XML: irc.terra.es
Example chat web client using XMLSocket: http://www.terra.es/chat
nice idea?
I not to program itself in c, write this post in case somebody is animated to do it
g00d bye
http://www.wdmedia.org/WIG/index-en.html
The script is written in php. It's working best on *nix. It's not tested on Windows systems.
I tried to hack the unreal source some time ago to add this as a configurable feature. The trick is to let the xmlsocket clients connect to another port, configured to send an extra \0 byte, using the same technique like for example ssl connections.
Here's my patch for 3.2.5. As it's just an attempt I can't assure it works like it should or doesn't break other features/clients.
I only provide this as PROOF OF CONCEPT, this is NOT to be intented to be used publically. Most of the code belongs to the unrealircd developers and this patch is not supported by them nor by me!
Unrealircd developers: please remove this post if it goes against your policy. It would be very nice to have this as feature though ...
[Moderator: Code removed. If you want this as an Unreal feature, make a patch for the current CVS and post a feature request on bugs.unrealircd.org. You might also be able to make a module to do this, since you're obviously OK with C]
Here's my patch for 3.2.5. As it's just an attempt I can't assure it works like it should or doesn't break other features/clients.
I only provide this as PROOF OF CONCEPT, this is NOT to be intented to be used publically. Most of the code belongs to the unrealircd developers and this patch is not supported by them nor by me!
Unrealircd developers: please remove this post if it goes against your policy. It would be very nice to have this as feature though ...
[Moderator: Code removed. If you want this as an Unreal feature, make a patch for the current CVS and post a feature request on bugs.unrealircd.org. You might also be able to make a module to do this, since you're obviously OK with C]
It doesn't require alot of code rewriting, just a listener and a client flag, and an extra line in the send code. If I provide the full source, why does it matter ? You can make the whole thing configurable, so it doesn't break any regular clients, it's the choice of the server admin to enable it on certain ports.
Flash does not work with regular sockets. It requires to zero-byte to trigger the onXML (and onData) event. It is however not required for the data to be xml, you can prototype the onData event to read the raw data. Most implementations now, like the one referenced higher in this post, rely on a (poorly written php) gateway to add the extra zero byte, causing alot of overhead (all connections doubled : client-gateway-server).
Line endings can be anything, so I suggest using \r\n\0, so just adding 1 to the length field in the send function if the client is using flash. Nothing will have to be rewritten ...
If unrealircd supports this out of the box, it will become very popular in the flash community. Isn't that what you want ? Adobe will never change flash to use normal sockets.
I can work this out completely, including documentation and examples to use IRC in flash. I can even write an irc client example in javascript then, using the flash externalinterface as bridge.
Flash does not work with regular sockets. It requires to zero-byte to trigger the onXML (and onData) event. It is however not required for the data to be xml, you can prototype the onData event to read the raw data. Most implementations now, like the one referenced higher in this post, rely on a (poorly written php) gateway to add the extra zero byte, causing alot of overhead (all connections doubled : client-gateway-server).
Line endings can be anything, so I suggest using \r\n\0, so just adding 1 to the length field in the send function if the client is using flash. Nothing will have to be rewritten ...
If unrealircd supports this out of the box, it will become very popular in the flash community. Isn't that what you want ? Adobe will never change flash to use normal sockets.
I can work this out completely, including documentation and examples to use IRC in flash. I can even write an irc client example in javascript then, using the flash externalinterface as bridge.
So the question still needs to be answered, why should an IRCd change to meet the needs of a client?
If all clients demanded the IRCd's change to fit some new/old/changed feature they included nobody would want to write/maintain IRCd's or the IRCd's would become way too complicated.
As has been the standard for years on the internet, clients are written to support the servers not the servers to support the clients.
So why should that change now?
If all clients demanded the IRCd's change to fit some new/old/changed feature they included nobody would want to write/maintain IRCd's or the IRCd's would become way too complicated.
As has been the standard for years on the internet, clients are written to support the servers not the servers to support the clients.
So why should that change now?
A company like Adobe will never change the flash socket implementation, probably for security reasons.
As I see it, the ircd has to be modified to support a whole new area of users and alot of new clients (written in flash, javascript, ...).
Give me a good reason NOT to implement it. With the patch I have NOTHING of the original IRC protocol is changed! It doesn't violate anything, just the line ending on certain ports, which doesn't need any change of the rest of the features of the ircd.
But also take a look at the cgi:irc support, since when isn't cgi:irc a client ? Well it's almost the same as flash, it's also a technology to allow a new type of clients connecting.
And also SSL/Ziplinks, since when are those part of the protocol ?
If you really have a problem with a feature that can be turned of via the configuration, then make a fork of the project, or make it a compile time flag.
I don't see why this should not be implemented, I'm willing to do ALL the work, the unreal devs will just have to merge it in the cvs trees.
As I see it, the ircd has to be modified to support a whole new area of users and alot of new clients (written in flash, javascript, ...).
Give me a good reason NOT to implement it. With the patch I have NOTHING of the original IRC protocol is changed! It doesn't violate anything, just the line ending on certain ports, which doesn't need any change of the rest of the features of the ircd.
But also take a look at the cgi:irc support, since when isn't cgi:irc a client ? Well it's almost the same as flash, it's also a technology to allow a new type of clients connecting.
And also SSL/Ziplinks, since when are those part of the protocol ?
If you really have a problem with a feature that can be turned of via the configuration, then make a fork of the project, or make it a compile time flag.
I don't see why this should not be implemented, I'm willing to do ALL the work, the unreal devs will just have to merge it in the cvs trees.
Firstly you made the point Adobe wont change, so what makes you think Unreal will?
Secondly Flash's socket implementation clearly wasnt designed for IRC in the first place.
Thirdly the CGI:IRC support is nothing to do with the protocol or the socket implementation anyway. CGI:IRC will work with Unreal even without Unreals CGI:IRC support. Unreals CGI:IRC support is so users real IP's/hosts show instead of the CGI:IRC server's IP/host. CGI:IRC works perfectly fine as a web hosted IRC client without Unreal's added support for it anyway. Just as CGI:IRC will connect to any other IRC compatible server.
Fouthly SSL works as a tunnel that IRC travels through. SSL can pretty much be applied to any protocol without much effort anyway. Ziplinks pretty much works on a similar principle except that its not implemented til after the intial connection registration.
Anyway to avoid this going on too long this is my last post and comments on this matter. I cant ever see a server changing to meet the needs of a client which by nature has always been built for the server theyre a client for. Since without the server, the client wouldnt exist anyway.
Secondly Flash's socket implementation clearly wasnt designed for IRC in the first place.
Thirdly the CGI:IRC support is nothing to do with the protocol or the socket implementation anyway. CGI:IRC will work with Unreal even without Unreals CGI:IRC support. Unreals CGI:IRC support is so users real IP's/hosts show instead of the CGI:IRC server's IP/host. CGI:IRC works perfectly fine as a web hosted IRC client without Unreal's added support for it anyway. Just as CGI:IRC will connect to any other IRC compatible server.
Fouthly SSL works as a tunnel that IRC travels through. SSL can pretty much be applied to any protocol without much effort anyway. Ziplinks pretty much works on a similar principle except that its not implemented til after the intial connection registration.
Anyway to avoid this going on too long this is my last post and comments on this matter. I cant ever see a server changing to meet the needs of a client which by nature has always been built for the server theyre a client for. Since without the server, the client wouldnt exist anyway.
You can see the flash xmlsocket thing also as something on top of the regular irc protocol. It's the same principle.
I just don't get, why not go against the normal philosophy and implement it ? Does it harm anyone ? Flash is not a client, it's a technology.
But ok, I will drop the subject. Close the topic please.
I just don't get, why not go against the normal philosophy and implement it ? Does it harm anyone ? Flash is not a client, it's a technology.
But ok, I will drop the subject. Close the topic please.