1:33 PM
To: hlds_linux@list.valvesoftware.com
Subject: Re: [hlds_linux] erm question
On 7/19/05, Simon Lange <[EMAIL PROTECTED]> wrote:
> is anyone interested in the infrastructure of the city of moscow,
> kiev, whatever?!
> NO!
Well since the subject here got onto multicasting, and the po
On 7/19/05, Simon Lange <[EMAIL PROTECTED]> wrote:
> is anyone interested in the infrastructure of the city of moscow, kiev,
> whatever?!
> NO!
Well since the subject here got onto multicasting, and the poster's
original point was about Moscow using LAN structures (valid in this
context) AND other
mailto:[EMAIL PROTECTED] On Behalf Of krio the d34d1
> Sent: Tuesday, July 19, 2005 12:25 PM
> To: hlds_linux@list.valvesoftware.com
> Subject: Re: [hlds_linux] erm question
>
> exactly, just not for a block, for the whole area of like 20-30 nearby
> buildings in a one-segment lan
>
is anyone interested in the infrastructure of the city of moscow, kiev,
whatever?!
NO!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of krio the d34d1
Sent: Tuesday, July 19, 2005 12:25 PM
To: hlds_linux@list.valvesoftware.com
Subject: Re: [hlds_linux] erm
exactly, just not for a block, for the whole area of like 20-30 nearby
buildings in a one-segment lan
2005/7/19, Andrew Forsberg <[EMAIL PROTECTED]>:
> I'm pretty sure he means that in Moscow most apartment blocks, or groups
> of blocks, are wired up as LANs, complete with their own gaming servers
gah, ok.
here.
the whole town is splitten up into like 10-20 lans, each controlled by
a seperate company providing internet access over the lan in their
regions (isa, vpn or routed)
each lan most likely has only 1 segment.
why?
couse of local, in the lan p2p servers and such. and lan traffic is
usu
I'm pretty sure he means that in Moscow most apartment blocks, or groups
of blocks, are wired up as LANs, complete with their own gaming servers,
irc & p2p servers, etc. As opposed to individuals in each apartment
buying their own ADSL connection, the body corporate buys bandwidth for
the entire b
I'm sorry, but I have no concept of what you are trying to describe.
On 7/19/05, krio the d34d1 <[EMAIL PROTECTED]> wrote:
> sry, my bad, i ment in a one segment.
> "they" is lan p2p servers etc.
> free of charge, in the same segment of lan.
> compare it with adsl isps.
>
> 2005/7/19, James Tucker
sry, my bad, i ment in a one segment.
"they" is lan p2p servers etc.
free of charge, in the same segment of lan.
compare it with adsl isps.
2005/7/19, James Tucker <[EMAIL PROTECTED]>:
> On 7/18/05, krio the d34d1 <[EMAIL PROTECTED]> wrote:
> > here in moscow lans are almost at every building,
>
>
Yeah, there is. We've played with it before during a tournament - using
multicast between our HLTV proxy and DSL users connected to our upstream, the
bandwidth saved was barely noticeable.
Like I said before I can only really see this working with an enormous viewer
base - and even then you cou
IIRC there is some multicast support in hltv?
On 7/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Multicast also only works if everyone behind the enabled segment wants the
> same data, and with every player on the server (using bugger all bandwidth
> anyway) having a different location o
Multicast also only works if everyone behind the enabled segment wants the same
data, and with every player on the server (using bugger all bandwidth anyway)
having a different location on the map, seeing different users etc, I can't see
it working at all. Unless you make the server send the sam
On 7/18/05, krio the d34d1 <[EMAIL PROTECTED]> wrote:
> here in moscow lans are almost at every building,
So you have a nice lan infrastructure on some kind of switch, IP aware or not.
> a usual net wich is
> used as a plot for isp is about 20-30 buildings, with like 50 flats
> connected at each,
here in moscow lans are almost at every building, a usual net wich is
used as a plot for isp is about 20-30 buildings, with like 50 flats
connected at each, in a one, not clustered lan. such a scenario is a
pain in the ass, but is required over here to have a good inner
comunity and compete with ad
On Monday, July 18, 2005 2:06 am, krio the d34d1 said:
> on a lan cutting down 94% of traffic is a thing for wich a lan
> operator could kill someone, believe me =)
> and over the internet - its server admin's problems to work things out
> with isp and considering the possible 94% cut - it worths
On 7/18/05, krio the d34d1 <[EMAIL PROTECTED]> wrote:
> on a lan cutting down 94% of traffic is a thing for wich a lan
> operator could kill someone, believe me =)
> and over the internet - its server admin's problems to work things out
> with isp and considering the possible 94% cut - it worths it
It is entirely sensitive for the time it is in transit, transit
carriers can't be trusted, where as it is assumed that Source run-time
code can be.
On 7/18/05, krio the d34d1 <[EMAIL PROTECTED]> wrote:
> you dont encrypt your http traffic if using a proxy, though you
> should, why should you encry
Hi
On 18.07.05 at 12:50:23 [+0200], krio the d34d1 <[EMAIL PROTECTED]> wrote:
> as ive said, world isn't perfect, and people aint
>
> in the deep future this could be done with multicasting as well. we
> group clients into visibility groups and put them dinamically on a
> seperate multicast channe
as ive said, world isn't perfect, and people aint
lets go a bit deeper.
forget about multicast for a second.
why should the server really send the *whole* snapshot to the client?
why dont we frestrum out the view on the server side and send only the
needed data to each client? we kill all the wall
Do you honestly think if it served no purpose they'd leave it in?
On 7/18/05, krio the d34d1 <[EMAIL PROTECTED]> wrote:
> on the lan env its spoofable even with encryption, exploits are in the
> wild, its a matter of sniffing the challange, so on that arena this
> doesn't change anything.
--
Cla
on the lan env its spoofable even with encryption, exploits are in the
wild, its a matter of sniffing the challange, so on that arena this
doesn't change anything.
2005/7/18, Clayton Macleod <[EMAIL PROTECTED]>:
> *sigh* I thought the whole reason encryption was used was because of
> certain cheat
*sigh* I thought the whole reason encryption was used was because of
certain cheats out there that were in use pre-encryption...
On 7/18/05, krio the d34d1 <[EMAIL PROTECTED]> wrote:
> you dont encrypt your http traffic if using a proxy, though you
> should, why should you encrypt publicly availib
you dont encrypt your http traffic if using a proxy, though you
should, why should you encrypt publicly availible coords then? it
doesn't make any sense, the snapshot data isn't sensitive
2005/7/18, Clayton Macleod <[EMAIL PROTECTED]>:
> proxies?
>
> On 7/18/05, krio the d34d1 <[EMAIL PROTECTED]>
proxies?
On 7/18/05, krio the d34d1 <[EMAIL PROTECTED]> wrote:
> and im not really sure why should the snapshots be encrypted.. the
> rest data - yeah, but the snapshots with coords etc...
--
Clayton Macleod
___
To unsubscribe, edit your list preferen
>No. Not really. If you are LAN'ing, then there is no point as I've
>said previously, so lets take the example of connecting via the
>internet... You have an ISP... While they *may* run some multicast
>routing protocol (PIM for example), they will not extend that to the end
>user. They will no
On 7/17/05, Steve Dalberg <[EMAIL PROTECTED]> wrote:
> Lastly, and I'm not sure on this, but I don't believe that
> all updates from a server to client are identical, but I'm not sure...
"Game data is compressed using delta compression to reduce network
load. That means the server doesn't send a f
krio the d34d1 wrote:
i've said "as an option" oh and yeah, its ok to multicast to those
only who support it and unicast to the rest, isn't it?
No. Not really. If you are LAN'ing, then there is no point as I've
said previously, so lets take the example of connecting via the
internet... You
Well, not yet.. I've messed around with mBGP and it's just not useful
right now..
At 01:40 PM 7/17/2005, Steve Dalberg wrote:
Ok, it appears that you have heard about multicast, but haven't actually
tried to use it... First thing, the application (server and client)
would have to support it...
i've said "as an option" oh and yeah, its ok to multicast to those
only who support it and unicast to the rest, isn't it? plus a bit of
control over it for server admins and we hit the jackpot in the near
future.
2005/7/17, e-Plutonia <[EMAIL PROTECTED]>:
> IPv6 in US, yes at least 1/2 a decade,
IPv6 in US, yes at least 1/2 a decade, in europe, they may have parts
set with IPv6, in which case, implementing this in the near future
would not be such a dumb idea. And also considering that right now
IPv6 > IPv4 & vice versa translations are possible. Just not multicast
traffic yet.
On 7/17/05
Ok, it appears that you have heard about multicast, but haven't actually
tried to use it... First thing, the application (server and client)
would have to support it... Second, this would only work on a LAN or
enterprise environment, as internet carriers do not share multicast
routing info. And
why not to use multicast, probably as an option, for server -> clients
packet flow?
lets see.
let "a" be the ammount of bytes to be send to specify a full one
player state at a frame(coords or whatever)
let "n" be the number of players.
current way, if i get it right:
clients -> server: a*n
server
32 matches
Mail list logo
