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 -
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 SCT
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:
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 t
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 composing notification, they c
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
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
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
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 can
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. C
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 u
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
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 protoco
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 su
-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
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
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 n
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 pract
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 _thi
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 bandw
20 matches
Mail list logo