Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Another For Paul (new transports)

1 view
Skip to first unread message

Roberto Nicchi

unread,
Dec 11, 2002, 1:20:48 PM12/11/02
to
> The only problems I had were with the Broadcasting, this personally
> is'nt a problem for me as I never use the Listen for Broadcasts etc.
>

what problems ? I use this FF feature and i'm thinking to use the new
protocols when available for 2.13


Roberto

Keith Johnson

unread,
Dec 11, 2002, 1:02:35 PM12/11/02
to
Hi Paul,

I've been playing with the new transports, and using your Benchmark
program, here are the results..

Relative to Legacy TCP speed = 1.0
SharedMem: 15.8 times faster than Legacy TCP
Blocking TCP: 5.1 times faster than Legacy TCP
Legacy SUP: 2.2 times faster than Legacy TCP

Timings based on a Sony Via Laptop 800 Mhz:

:-) looks nice..
What is realy nice, is that for most of our installations, I think they
could use SharedMem, this is because were using TSE, Citrix etc. (And I
beleive SharedMem works between sessions on one machine)..

The only problems I had were with the Broadcasting, this personally
is'nt a problem for me as I never use the Listen for Broadcasts etc.

I also used the new protocols in a new App I'm writing, got it working
with ease, never notised any difference with speed, but I don't think
this App is pushing FF yet..

Hope this info is of use, I'll keep you posted on any more finding..
etc..

Regards
Keith..

Paul Motyer [TPX]

unread,
Dec 11, 2002, 5:20:09 PM12/11/02
to
"Keith Johnson" wrote

> :-) looks nice..

thanks!

> What is realy nice, is that for most of our installations, I think
they
> could use SharedMem, this is because were using TSE, Citrix etc.
> (And I beleive SharedMem works between sessions on one machine)..

I've no experience here

> The only problems I had were with the Broadcasting

Broadcasting is a problem. It doesn't work well on the same machine -
it *does* work well if the client and server are on separate machines
though

The legacy transports don't log broadcasts - and don't respect the
timeout either using 500 msec every time. This means the Legacy
Transport sometimes fails to connect where the server & Client are on
differing machines as well if 500 msec is insufficient

But mine does (logs UDP Packets that is) so you can watch the FFServer
display and see the UDP packets come in as an increase in the message
count. Whilst amazing, sometimes when the Client does a broadcast *no*
packets are received

I think my TCP Transport is more robust re broadcasting than the
Legacy one

> Hope this info is of use, I'll keep you posted on
> any more finding.. etc..

It's great - thanks

--
,-._|\ Paul Motyer [TPX]
/ Oz \ SoftStuff P/L
\_,--._/ [paul.motyer at tpx.turbopower dot com]
v [ http://members.optushome.com.au/paulmotyer ]


Sean Winstead [TurboPower]

unread,
Dec 11, 2002, 6:05:14 PM12/11/02
to

>The legacy transports don't log broadcasts...

Listening transports will log a received broadcast if transport
logging is enabled. It doesn't affect msg count.

>and don't respect the
>timeout either using 500 msec every time. This means the Legacy
>Transport sometimes fails to connect where the server & Client are on
>differing machines as well if 500 msec is insufficient

Fixed in 2.13.


Paul Motyer [TPX]

unread,
Dec 11, 2002, 9:13:44 PM12/11/02
to
"Keith Johnson" wrote

> So I wonder when Paul will be ready for PayPal?

When it's ready! By ready I mean tested in the wild at several of my
beta sites. I think it's really robust right now

I'm porting over all my FF1 Apps. That is a huge task because I had so
many FF1 customizations. It should be done in a couple of weeks then I
can get some of my beta sites testing it

> source code to the benchmark program,
> Paul's indent style is unique. <g>

I find that indent style really easy to understand because begin/ends
are all matched - I find the Borland/TPS style confusing.

However, it's certainly possible it may get changed to the TPS style
for consistency

> Also I've noticed when the Client is searching for
> a server the Message Count on the server goes up
> (in fact it goes up by 16),

The Client sends a max of 4 broadcasts, the server replies twice to
each received broadcast - immediately and after a short delay (50
msec)

Keith Johnson

unread,
Dec 11, 2002, 7:04:46 PM12/11/02
to
Roberto Nicchi <soft...@masterinformatica.net> wrote in
news:Xns92E1C4C9BFB25so...@65.166.141.191:

> what problems ? I use this FF feature

Hi Roberto,

Most likely the same ones Paul has mentioned, as I'm currently only
using the protocol localy. I don't use Listen for broadcast feature
using the Legacy Transport either, one of the advantages is that
connection time is much faster if you don't. My Laptop also has 3
network cards, so I think something might be eating the UDP packets,
saying that the Legacy broadcast did work, so I'm not sure. mmmm, I
wonder if that is the reason, multiple network cards???

> and i'm thinking to use the new
> protocols when available for 2.13

Same here, I'm currently using them during development.

So I wonder when Paul will be ready for PayPal?. It would be
interesting to see the source code, something I did notice with the

source code to the benchmark program, Paul's indent style is unique. <g>

Keith,

0 new messages