Thread: Re: [email] RE: [GD-General] A portable preferences library
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: J C L. <cl...@ka...> - 2003-12-05 04:19:48
|
On Thu, 4 Dec 2003 16:49:45 -0800 Colin Fahey <cp...@ea...> wrote: > All user preferences and patched files can be placed or retrieved from > the application archive by a login (decryption key), but a hacker > cannot cause any predictable change to the application or its data. You may like to do some reading up on capability models and the use of capability models in security. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: <Per...@ep...> - 2004-03-23 11:15:09
|
its dynamic data... will check zlib... I prefer not to make yet not an other compression utility (did that first, but realized soon that supporting it our self was not nescerry whan others had invented the "wheel" before:-) Regards Per -----Original Message----- From: Brian Hook [mailto:ho...@py...] Sent: 22. mars 2004 16:59 To: gam...@li... Subject: Re: [GD-General] Compress/Uncompress > Do you know any compress/uncompress software that can be used ? What language? What kind of data? Dynamic or static data? Without knowing anything else, a lot of people use zlib to incorporate in-lined compression, yet others roll their own compressors (arithmetic or huffman), etc. Brian ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU7 |
|
From: <ma...@ch...> - 2004-03-23 12:00:56
|
On Tue, 23 Mar 2004, Per Løvmo wrote:
> its dynamic data...
>
> will check zlib...
>
> I prefer not to make yet not an other compression utility (did that first,
> but realized soon that supporting it our self was not nescerry whan others
> had invented the "wheel" before:-)
The counter argument, obviously, is that because you know a lot about your
data, you may be able to design a better algorithm (better compression,
faster), than what you can obtain by using a general one.
Both gz, and bz2 are quite general.
Mads
--
Mads Bondo Dydensborg. ma...@ch...
If you aim the gun at your foot and pull the trigger, it's UNIX's job to
ensure reliable delivery of the bullet to where you aimed the gun (in
this case, Mr. Foot).
- Terry Lambert, FreeBSD-Hackers mailing list.
|
|
From: <Per...@ep...> - 2004-03-23 12:10:47
|
In some cases, yes, I know exactly what data is to be transfered (like
comands etc.), and since they are small anyhow, I "only" encrypt =
them...
But when it comes to actual general data being transfered, I can not =
know
more than its data I want to transfered...
And therby I have landed on trying to use a general compress/uncompress
utility
** so far zlib seems to be faster than bz2 :-) **
Regards
Per
-----Original Message-----
From: ma...@ch... [mailto:ma...@ch...]
Sent: 23. mars 2004 13:01
To: 'gam...@li...'
Subject: RE: [GD-General] Compress/Uncompress
On Tue, 23 Mar 2004, Per L=F8vmo wrote:
> its dynamic data...
>=20
> will check zlib...=20
>=20
> I prefer not to make yet not an other compression utility (did that =
first,
> but realized soon that supporting it our self was not nescerry whan =
others
> had invented the "wheel" before:-)
The counter argument, obviously, is that because you know a lot about =
your=20
data, you may be able to design a better algorithm (better compression, =
faster), than what you can obtain by using a general one.
Both gz, and bz2 are quite general.
Mads
--=20
Mads Bondo Dydensborg. =
ma...@ch...
If you aim the gun at your foot and pull the trigger, it's UNIX's job =
to=20
ensure reliable delivery of the bullet to where you aimed the gun (in
this case, Mr. Foot).=20
- Terry Lambert, FreeBSD-Hackers mailing
list.
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
|
|
From: Ivan-Assen I. <as...@ha...> - 2004-03-23 12:21:53
|
> The counter argument, obviously, is that because you know a lot about your > data, you may be able to design a better algorithm (better compression, > faster), than what you can obtain by using a general one. I would seek improvement in compression ratio by preprocessing the data I feed to zlib based on what I know about it (e.g. taking deltas), instead of implementing a new algorithm. It's hard to imagine a scenario where you can't afford the compression time used to transform through zlib data which has to be transmitted (at typical network speeds) or stored (at typical HDD speeds). |
|
From: Colin F. <cp...@ea...> - 2004-04-12 23:10:21
|
2004 April 12th
Monday
(1) What size limit on UDP packets is imposed by the
UDP specification?
(2) What size limit on UDP packets is imposed by the
operating system (Windows, Linux, ...), and how
can I query the OS for these limits?
(3) What is the practical limit of UDP packets going across the
wild Internet, through dozens of routers with various
policies?
(I know UDP is "unreliable", but I'd like to push UDP
packet size as high as possible without significantly
increasing the risk of UDP packets being quietly
dropped along the route to their destinations.)
My ignorant guesses would be the following:
(1) Less than limit on payload part of single Ethernet
frame: (1526 Bytes - 26 Bytes) = 1500 Bytes (roughly)
(2) Same as (1)
(3) Same as (1)? Or perhaps much less (realistically speaking)?
--- Colin
cp...@ea...
|
|
From: J C L. <cl...@ka...> - 2003-12-05 10:56:40
|
On Thu, 4 Dec 2003 12:42:12 -0800 Colin Fahey <cp...@ea...> wrote: > Basically, I'm a strong believer of the settings following the > application around. I think the old MacIntosh operating system hid a > kind of directory system behind the application icon -- with the > "resource fork" and "data fork", which was a pretty good idea because > it allowed data associated with a program to be bound to the program. Windows allows this as well under NTFS ala extended attributes, tho it is not commonly used. Linux allows extended attributes under Ext[23]fs but not ReiserFS or XFS IIRC. > Maybe I'm hard-core, but I think everything an application needs to > operate, short of the absolutely guaranteed resources of the operating > system, should be packaged with the application -- and totally > portable. In the case of user preferences this violates the model of segmented access rights and patterns as it requires that users have write access to the installation point the application. Stackable filesystems are one way around this, but are extremely unlikely to be widely deployed. Logical view based filesystems are a possible address if you insist on the model, but that's even further out. > I should be able to run any application on anyone's computer from my > keychain memory device, without adding any files to their computer! Limited execution environments, be it capability systems, trusted computing, or execution models will be and often already are the first hurdles there. If the OS physically won't allow execution of a file which is not on a pre-configured trusted device... > I think multi-user systems is an antiquated concept. <shrug> And yet they are becoming more common. > But if I must support multiple users of a single application (as > opposed to each user installing his or her own copy of the > application), then individual preferences files can be stored with the > application. Which in turn requires write access to the installation location. Not a winner. > Lots of irresponsible developers don't do a good job of > un-installation -- or somehow the application disappears from the > computer without un-install ever happening, leaving tons of scattered > junk behind. There are two disparate concepts: removing access/configuration data from a user, and removing the entire application from a system. They are different and disjoint. Removing an application from a system in no means that each user's configuration data must also be removed (well, not unless you want some extremely unhappy users). > I think rather than pushing itself upon one's computer (like a formal > installation procedure), applications should be passive and the > operating system should instead scan for applications upon boot-up. Quibble: My desktop boots perhaps twice a year if that... -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: Tom S. <to...@pi...> - 2003-12-05 19:32:11
|
> -----Original Message----- > Behalf Of J C Lawrence > > Maybe I'm hard-core, but I think everything an application needs to > > operate, short of the absolutely guaranteed resources of > the operating > > system, should be packaged with the application -- and totally > > portable. > > In the case of user preferences this violates the model of > segmented access rights and patterns as it requires that > users have write access to the installation point the > application. Maybe one that wants to maintain application controlled config selection ala BF1942 for instance, yet not violate the write access of non-admin accounts should use SHGetFolderLocation( CSIDL_COMMON_APPDATA ), CSIDL_COMMON_DOCUMENTS, or whatever is equivalent to 'C:\Documents and Settings\All Users\' in other OSs. Tom |
|
From: Colin F. <cp...@ea...> - 2004-04-13 00:42:21
|
2004 April 12th Monday Well, I'll roughly summarize what I encountered while doing Google searching for answers, but perhaps people can add experiences or other hard facts to this thread. The limit for UDP data size is theoretically 65535 bytes, just based on the unsigned 16-bit UDP Message Length field in a UDP datagram. Then this is reduced by 28 bytes due to the fact that IP packets also must be a maximum of 65535 bytes, and require their own fields (headers and final CRC) -- reducing the theoretical UDP data size to 65507 bytes (a number quoted in various sources one can find via Google). However, according to one source, many OSes put an upper limit of 8192 bytes on the UDP receive buffer, which puts further limit on individual UDP packet sizes. (I assume this is after any packet re-assembly after potential fragmentation, since the receive buffer is "session layer"?) Other sources say that the 1526 byte-max Ethernet frame size (Ethernet's "Maximum Transmission Unit" (MTU) size) puts another de facto limit on UDP packet size -- since data larger than the 1500-byte payload limit for a single Ethernet frame is necessarily fragmented, and apparently some routing policies often don't call for working very hard to handle fragmented UDP packets. One source said that really the only way to be confident was to go all the way down to the minimum guaranteed UDP packet size handled by hosts complying with specs: 512 bytes. One source said the following (as a "moral"): "Avoid UDP if you really require reliable transmission of large messages, otherwise you end up reinventing TCP protocol". Clearly UDP is great for many purposes, and TCP is great for many other purposes. Assuming UDP is the right choice for a given purpose, it is interesting to consider the actual constraints imposed by the wild Internet. --- Colin cp...@ea... |
|
From: Brian H. <ho...@py...> - 2004-04-13 01:07:07
|
> Clearly UDP is great for many purposes, and TCP is great for many > other purposes. Assuming UDP is the right choice for a given > purpose, it is interesting to consider the actual constraints > imposed by the wild Internet. http://enet.cubik.org Brian |
|
From: Nicolas R. <nic...@fr...> - 2004-04-13 07:18:54
|
> (1) What size limit on UDP packets is imposed by the > UDP specification? IP Packet maximal size is 65535. When removing IP/UDP headers (28 bytes), you get a max data size of 65507 bytes. > > (2) What size limit on UDP packets is imposed by the > operating system (Windows, Linux, ...), and how > can I query the OS for these limits? Don't know any OS "adding" limits on UDP packets. Wouldn't be compliant with standards. Some socket options do contain the max size for a given socket. > > (3) What is the practical limit of UDP packets going across the > wild Internet, through dozens of routers with various > policies? Strictly speaking of UDP packets, nothing else. Note however that when a packet size is greater than a given value (MTU), it might be fragmented into several packets and recombined later when possible. This can happen several time on each router. Usually that MTU is around 1500 bytes. It is strongly encouraged when communicating with another host to discover the MTU on the path. Though the path may change (and therefode MTU) it is unlikely to happen very often. Using MTU max size for packets will avoid adding extra IP/UDP headers during communication. > > (I know UDP is "unreliable", but I'd like to push UDP > packet size as high as possible without significantly > increasing the risk of UDP packets being quietly > dropped along the route to their destinations.) > Simple: If your packet is fragmented into 'n' smaller ones, the final packet will be lost 'n' times more often ! :) So basically, the chance to loose a packet is around (Size/MTU) bigger. Nicolas --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.656 / Virus Database: 421 - Release Date: 09/04/2004 |
|
From: J C L. <cl...@ka...> - 2004-04-15 03:09:01
|
On Mon, 12 Apr 2004 16:12:48 -0700 Colin Fahey <cp...@ea...> wrote: > (3) What is the practical limit of UDP packets going across the wild > Internet, through dozens of routers with various policies? I've found that (older?) routers drop/not-reassemble UDP fragments often enough to be painful. As such I'd suggest doing periodic MTU discovery and keeping within that boundary. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X