| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 08 10:47PM -0700 On 7/8/2023 12:26 PM, Bonita Montero wrote: >> I think a lot of them (games) use UDP instead of TCP. > Of course. That's while you don't need re-transmits because > they would reach the other parties too late anyway. Actually, I remember way back on my nt 4.0 days, this might of been around 2001-2002 ish... I would have a single TCP connection for control then a bunch on UDP connections to send datagrams. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 09 10:44AM +0200 Am 09.07.2023 um 07:47 schrieb Chris M. Thomasson: > Actually, I remember way back on my nt 4.0 days, this might of > been around 2001-2002 ish... I would have a single TCP connection > for control then a bunch on UDP connections to send datagrams. I'm pettifogging: you never had UDP-_connections_. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 09 02:41AM -0700 On 7/9/2023 1:44 AM, Bonita Montero wrote: >> been around 2001-2002 ish... I would have a single TCP connection >> for control then a bunch on UDP connections to send datagrams. > I'm pettifogging: you never had UDP-_connections_. It was many years ago. Iirc, I would have a single TCP connection for status and send out datagrams via UDP. It was kind of like the zmodem protocol. I remember using a multiplex in the TCP connection to embedded multiple status messages for different sockets. UDP was the main usage. TCP was there to maintain a lossless comm. UDP datagrams can get lost and/or duplicated, iirc. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 09 02:43AM -0700 On 7/9/2023 2:41 AM, Chris M. Thomasson wrote: > multiple status messages for different sockets. UDP was the main usage. > TCP was there to maintain a lossless comm. UDP datagrams can get lost > and/or duplicated, iirc. I remember putting in some state in the datagrams. So, if they arrived out of order, I could put them back together. Or, they just knew where to be written to a memory mapped file. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 09 02:55AM -0700 On 7/9/2023 1:44 AM, Bonita Montero wrote: >> been around 2001-2002 ish... I would have a single TCP connection >> for control then a bunch on UDP connections to send datagrams. > I'm pettifogging: you never had UDP-_connections_. Basically, I would try to send a file offset in the datagrams. The receiver of a single datagram knew where to write it in a memory mapped file. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 09 02:59AM -0700 On 7/9/2023 2:55 AM, Chris M. Thomasson wrote: > Basically, I would try to send a file offset in the datagrams. The > receiver of a single datagram knew where to write it in a memory mapped > file. Damn Bonita! You are making my brain think of things I did long ago... This is why I had a TCP connection to be able to reliably request more data until the memory mapped file was full via UDP datagrams filling it up, so to speak... :^D |
| David Brown <david.brown@hesbynett.no>: Jul 09 12:38PM +0200 On 08/07/2023 16:19, Bonita Montero wrote: >> I've tried to explain things to you, as has Scott. Clearly, it is >> all so far beyond you that the Dunning Kruger effect has taken over. > His reasoning is really 180 degrees opposite of mine, Yes - because he knows what he is talking about - he has the computers there, in his lab - and you haven't a clue. Can you really not see that? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 09 03:42AM -0700 On 7/9/2023 3:38 AM, David Brown wrote: >> His reasoning is really 180 degrees opposite of mine, > Yes - because he knows what he is talking about - he has the computers > there, in his lab - and you haven't a clue. Can you really not see that? YIKES! ;^/ |
| David Brown <david.brown@hesbynett.no>: Jul 09 12:43PM +0200 > There's also a large amount of state about everything else going on > in the simulated world that has to be uploaded to each player which has to be > kept in sync. Yes, that would be another type of application where the server would need very fast network card(s). It's a different case from Scott's, since online games generally aim for smaller amounts of data at a time but handle vast numbers of connections (hundreds of thousands, or more) and also want lower latencies. For Scott's file servers, there are only hundreds of client machines, but the data files are very large and the simulations generate massive quantities of data as they go along. But it is certainly an application for which you want as fast networking as you can afford on the server. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 09 03:50AM -0700 On 7/9/2023 3:43 AM, David Brown wrote: > simulations generate massive quantities of data as they go along. But > it is certainly an application for which you want as fast networking as > you can afford on the server. Fwiw, I am wondering of anybody else got pissed off at the nt 4.0 client version only allowing for two concurrent TransmitFile IOCP functions to be allowed at any one time? The nt 4 server allowed for enough concurrent TransmitFile's to blow the non-paged memory. Grrr! |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 09 01:46PM +0200 Am 09.07.2023 um 11:41 schrieb Chris M. Thomasson: > On 7/9/2023 1:44 AM, Bonita Montero wrote: >> I'm pettifogging: you never had UDP-_connections_. > It was many years ago. Iirc, ... UDP is connectionless and stateless. |
| Muttley@dastardlyhq.com: Jul 09 12:18PM On Sat, 8 Jul 2023 21:25:16 +0200 >> in the simulated world that has to be uploaded to each player which >> has to be kept in sync. >I'm pretty sure you've never worked on things like that. Bonita playbook rule #1: If proven wrong accuse other person of knowing nothing/being an idiot/lying etc. Perhaps look in the mirror occasionally. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 09 03:38PM +0200 > Bonita playbook rule #1: If proven wrong accuse other person of knowing > nothing/being an idiot/lying etc. > Perhaps look in the mirror occasionally. If you make realtime transfers you can't afford to make large transfers because they'd have a large latency until being received by other parties. |
| scott@slp53.sl.home (Scott Lurndal): Jul 09 03:37PM >version only allowing for two concurrent TransmitFile IOCP functions to >be allowed at any one time? The nt 4 server allowed for enough >concurrent TransmitFile's to blow the non-paged memory. Grrr! Can't say I've ever actually used NT4 for anything. Or any windows release for that matter. In the NT4 timeframe, I was still using large IRIX machines and NT was considered a toy. We did have a source license for NT4 and modified it to use as one of our supported guest OS' in early hypervisor skunkwork (1998/1999) at SGI, so I was, at the time, quite familiar with the NTOS portions of windows (which were strikingly similar to the VAX VMS internals that I worked with in the early 80's). |
| David Brown <david.brown@hesbynett.no>: Jul 09 05:37PM +0200 On 07/07/2023 19:31, Kalevi Kolttonen wrote: > across this RTL: > https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gccint/RTL.html > Does it have anything to do with the RTL you guys use? In both cases, the abbreviation means "Register transfer level". But they are different kinds of register. For the compiler, you are talking about processor registers (typically matching a 32-bit or 64-bit integer, double precision floating point, or possibly SIMD vector). RTL is then about transforming the program into virtual operations that are register to register, or register op register to register. In logic design, whether it be programmable logic (FPGA's), ASICs, or full-blown digital logic chips, a "register" is a single storage bit, and RTL covers input to the register as combinational logic of signals, clocking, enables, reset lines, and possible asynchronous overrides. There's a lot that goes on for each single bit here, to describe it and how it works, to simulate it, and to record its state and output. It's not just the logical states - timing has to be taken into account too. And while you can do bulk simulation for things like caches and static rams, there are still hundreds of millions of gates to simulate in these big chips. (There are also other kinds of simulations needed for power usage, timing closure, fanouts, etc.) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 09 01:14PM -0700 On 7/9/2023 4:46 AM, Bonita Montero wrote: >>> I'm pettifogging: you never had UDP-_connections_. >> It was many years ago. Iirc, ... > UDP is connectionless and stateless. Just read datagrams from a bound socket. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jul 09 04:09PM -0700 >> Does it have anything to do with the RTL you guys use? > In both cases, the abbreviation means "Register transfer level". But > they are different kinds of register. [...] In the gcc documentation, RTL means "Register Transfer Language". -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| wij <wyniijj5@gmail.com>: Jul 09 08:29AM -0700 On Tuesday, July 4, 2023 at 12:32:17 AM UTC+8, wij wrote: > _.. prefix for system-specific members or candidate, or restricted..etc. > wy_.. prefix for internal members (for testing, etc.). > ------ A section about throwing error is added to libwy guidelines, posted for review. -------- Throwing error As an elementary library, libwy has to make any error report of provided functions be able properly handled by its caller to accomplish the function requested and don't create exception. Throwing error loses the context information. FUNCTIONS (and ctor/dtor/..) SHOULD CATCH ALL CONFUSING ERRORS THROWN TO CONVERT TO THE ONE IT IS RESPONSIBLE. Difficulty exists to achieve this requirement especially for template classes, therefore, libwy should minimize using template in general (Array<T> seems to defy this rule...). Note: Implement should also consider other things like thread cancellation and signal-safety. +--------------------------+ | Appendix: Losing Context | +--------------------------+ The error thrown may not associate to the function being called. int read_integer(size_t maxlen) { int v; if(maxlen>10) { throw Invalid_Argument; } // read string and convert to integer (Invalid_Argument may be thrown) return v; } void f(int count) { int v; if(count<0) { throw Invalid_Argument; } for(int i=0; i<count; ++i) { try { v= read_integer(8); } catch (Invalid_Argument) { // May not be the Invalid_Argument in read_integer(..) thrown. // Decisions based on this assumption will be wrong. } } } The Invalid_Argument caught in f may not mean the argument of read_integer(..) is invalid. Likewise, if Invalid_Argument is rethrown or passed, it does not necessarily mean the argument 'count' of f is invalid. ----------- |
| Paavo Helde <eesnimi@osa.pri.ee>: Jul 09 06:44PM +0300 09.07.2023 18:29 wij kirjutas: > int v; > if(maxlen>10) { > throw Invalid_Argument; I can see now what you mean by "losing context". It has never occurred to me to throw such meaningless exceptions. Try something like this instead: throw std::runtime_error( "Invalid parameter maxlen=" + std::to_string(maxlen) + " passed to read_integer(), the value must be not larger than 10"); |
| wij <wyniijj5@gmail.com>: Jul 09 09:02AM -0700 On Sunday, July 9, 2023 at 11:44:39 PM UTC+8, Paavo Helde wrote: > "Invalid parameter maxlen=" + > std::to_string(maxlen) + > " passed to read_integer(), the value must be not larger than 10"); Your brain is stuffed by stdc++'s lie. "Losing Context" means it is DOOMED in C++ language. All the user can do is working around. |
| wij <wyniijj5@gmail.com>: Jul 09 09:09AM -0700 On Monday, July 10, 2023 at 12:03:03 AM UTC+8, wij wrote: |
| wij <wyniijj5@gmail.com>: Jul 09 09:12AM -0700 On Monday, July 10, 2023 at 12:03:03 AM UTC+8, wij wrote: > Your brain is stuffed by stdc++'s lie. > "Losing Context" means it is DOOMED in C++ language. All the user can do is > working around. Throwing std::runtime_error is like signaling a global object is updated. |
| wij <wyniijj5@gmail.com>: Jul 09 10:50AM -0700 On Sunday, July 9, 2023 at 11:44:39 PM UTC+8, Paavo Helde wrote: > "Invalid parameter maxlen=" + > std::to_string(maxlen) + > " passed to read_integer(), the value must be not larger than 10"); To be specific about such coding: throw std::runtime_error( "Invalid parameter maxlen=" + std::to_string(maxlen) + " passed to read_integer(), the value must be not larger than 10"); 0. Error report of a function (mostly) is made for the caller to know and handle. In this case, owing to the context loss issue, caller of a function generally won't be able to tell it is exactly the argument 'maxlen' causing the problem. Such coding as the above does not make things better in the general case. 1. Error report itself has to be error free. 2. Efficiency. Many of such error reports may happen and happen frequently. No one like to do the heavy decoding job everywhere. |
| Man <vvvvvvvvvvvvvvvvvvvvvvvvvvvvva@hotmail.com>: Jul 08 05:40PM -0700 Kuhu Sul ikka minna siit armsalt planeedilt nimega Maa ? Mina küll siit minema ei taha minna. On Saturday, July 8, 2023 at 11:24:51 PM UTC+3, Paavo Helde wrote: |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment