Remko Troncon wrote:
Not that I have experience with mobile devices, but if you use zlib, the
overhead of doing a ping should reduce to one byte plus a few bytes of
padding every call in every direction. If you do a ping every minute,
this bandwidth overhead is neglectable compared to the
Jesus Cea schrieb:
Magnus Henoch wrote:
I'm in no way an expert in network programming, so what I'm about to
write might qualify as disinformation; please write corrections or
completions.
How do you access to that info from python/java/erlang/god knows?.
Well, I don't think that _this_ is a
On Thu Nov 2 23:24:47 2006, Jesus Cea wrote:
I'm a bit worried about CPU/bandwidth explosión, nevertheless. And
mobile bandwidth, that pay per byte.
Also on mobile, the battery drain for transmission outweighs
everything else. The battery drain for receiving data isn't small
either. In
On Fri Nov 3 01:49:06 2006, Remko Troncon wrote:
Not that I have experience with mobile devices, but if you use
zlib, the overhead of doing a ping should reduce to one byte plus
a few bytes of padding every call in every direction. If you do a
ping every minute, this bandwidth overhead is
Alexander Gnauck wrote:
zlib is doing very well for me on pocket pc's and smartphones. And also
the compression rate is very good. It's on my TODO list for a very long
time now to post some stats. Going back to work now and do that ;-)
i attached 2 compression logs. This logs are from 2 short
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthias Wimmer wrote:
Well, I don't think that _this_ is a valid argument. It's not the task
of protocols to work around design restrictions in a language.
If this would be the task of a protocol, we would need some changes in
the protocol to
Jesus Cea [EMAIL PROTECTED] writes:
Matthias Wimmer wrote:
Well, I don't think that _this_ is a valid argument. It's not the task
of protocols to work around design restrictions in a language.
If this would be the task of a protocol, we would need some changes in
the protocol to support
On Fri Nov 3 14:33:54 2006, Magnus Henoch wrote:
Jesus Cea [EMAIL PROTECTED] writes:
Matthias Wimmer wrote:
Well, I don't think that _this_ is a valid argument. It's not
the task
of protocols to work around design restrictions in a language.
If this would be the task of a protocol, we
SCTP [1] is supposed to be fixing a lot of these issues. Support for
it is already available in the main *nixes, there is also a user space
library. Even Vista is going to support it! [2]
It might make sense in rfc3920bis to make a small note that SCTP can
be used as a 'drop in' replacement for
Norman Rasmussen wrote:
SCTP [1] is supposed to be fixing a lot of these issues. Support for
it is already available in the main *nixes, there is also a user space
library. Even Vista is going to support it! [2]
It might make sense in rfc3920bis to make a small note that SCTP can
be used
IMHO it's about time to actively deprecate the old message events
protocol (XEP-0022) in favor of chat state notifications (XEP-0085).
However, that means many clients will support both for a while. In
certain scenarios that can result in use of message events instead of
chat state notifications.
1. Romeo sends an initial chat message to Juliet with 85 + 22
extensions.
I think the main problem starts here: clients supporting both should
not be sending out XEP-22 information in the first place. Whenever
you are in the situation where the other client asks for XEP-22 only,
you
Remko Troncon wrote:
1. Romeo sends an initial chat message to Juliet with 85 + 22 extensions.
I think the main problem starts here: clients supporting both should not
be sending out XEP-22 information in the first place. Whenever you are
in the situation where the other client asks for
On Friday 03 November 2006 8:29 am, Peter Saint-Andre wrote:
Norman Rasmussen wrote:
It might make sense in rfc3920bis to make a small note that SCTP can
be used as a 'drop in' replacement for TCP as long as both hosts
supports it.
Will do. I still think it's not a great idea for us to be
Hello,
On Fri, Nov 03, 2006 at 10:50:37AM -0800, Justin Karneges wrote:
On Friday 03 November 2006 8:29 am, Peter Saint-Andre wrote:
Norman Rasmussen wrote:
It might make sense in rfc3920bis to make a small note that SCTP can
be used as a 'drop in' replacement for TCP as long as both
Olivier Goffart wrote:
Le vendredi 3 novembre 2006 18:36, Peter Saint-Andre a écrit :
IMHO it's about time to actively deprecate the old message events
protocol (XEP-0022) in favor of chat state notifications (XEP-0085).
But 85 and 22 are IMO two completely different things.
Appart the
I didn't know SCTP since you've mentioned it and have some questions:Is SCTP TCP compatible? When a server provides SCTP protocol on port 5222 for example normal TCP clients can still connect?Could both protocols run on one port?
TIATobiasOn 11/3/06, Michal 'vorner' Vaner [EMAIL PROTECTED] wrote:
On Friday 03 November 2006 11:00 am, Michal 'vorner' Vaner wrote:
On Fri, Nov 03, 2006 at 10:50:37AM -0800, Justin Karneges wrote:
On Friday 03 November 2006 8:29 am, Peter Saint-Andre wrote:
Norman Rasmussen wrote:
It might make sense in rfc3920bis to make a small note that SCTP can
Hi Michal!
Michal 'vorner' Vaner schrieb:
However, I would like to see XMPP over SCTP. Simply because it's ability
of multihoming (I may have written about it, I take laptop, start WiFi,
unplug ethernet and want to be still connected).
You get that with a full IPv6 implementation as well -
19 matches
Mail list logo
