27 Aug, 2008, Conner wrote in the 21st comment:
Votes: 0
Samson said:
Of all the things that have been updated in MUDs over the years you'd think the core networking code should have received some attention.

In fact, you'd think it'd even classify as a bug that some FUSS type project should've addressed, wouldn't you? :wink:
27 Aug, 2008, Kayle wrote in the 22nd comment:
Votes: 0
It's on my list of things to pursue a fix for. :P
27 Aug, 2008, David Haley wrote in the 23rd comment:
Votes: 0
The efficiency thing isn't really hard to fix if you know a thing or two about networking. I've done it a couple of times already. Of course, I made my life easier by converting large chunks of the code to proper C++ along the way…
27 Aug, 2008, Kayle wrote in the 24th comment:
Votes: 0
Well, thanks to Kiasyn, I have a couple of really good resources on network programming, so hopefully, that fix won't be too far off. :P
27 Aug, 2008, David Haley wrote in the 25th comment:
Votes: 0
I already have a huge chunk of code written and encapsulated. It would need to be updated to FUSS and whatnot but, well, it's probably faster to do that than to learn and write a new fix from scratch. I would need to take a look at it again and see if I'm not doing anything silly, but I have no objection to sending you the relevant classes.

EDIT:
well, it's not "huge". :wink: What I meant is "basically all relevant code".
27 Aug, 2008, Kayle wrote in the 26th comment:
Votes: 0
I wouldn't complain. :P
27 Aug, 2008, Lobotomy wrote in the 27th comment:
Votes: 0
DavidHaley said:
The efficiency thing isn't really hard to fix if you know a thing or two about networking. I've done it a couple of times already. Of course, I made my life easier by converting large chunks of the code to proper C++ along the way…

Right…but the thing is, I need to have an idea of how it's being inefficient before I can actually fix it in a way that will stand up to said perceptions of inefficieny. Sure, I could just go through and rewrite all the network code from the ground up (I may end up doing that anyways), but even amidst doing that if I haven't a clue of how the other sockets are being quantified as inefficient then the best thing I can do with regards to my own code is to just guess, and hope that somehow the result is what people want.
27 Aug, 2008, David Haley wrote in the 28th comment:
Votes: 0
I apologize, I thought I'd already said what the problem was. It's that the code tries to control the data flow where it shouldn't be. It shouldn't be limiting data flow to ticks. It should leave bandwidth management to the OS. This is w.r.t. SMAUG; I do not remember how SocketMUD works.
27 Aug, 2008, Lobotomy wrote in the 29th comment:
Votes: 0
DavidHaley said:
I apologize, I thought I'd already said what the problem was. It's that the code tries to control the data flow where it shouldn't be. It shouldn't be limiting data flow to ticks. It should leave bandwidth management to the OS. This is w.r.t. SMAUG; I do not remember how SocketMUD works.

I see, thank you. Yes you did mention that before (I remember now), although I had forgotten it amidst the rest of the conversation. Is that the only notable problem, or are there others?

Edit: I believe there might be something similar to that in Socketmud, if not exactly. I know that one of the designs I came across when I started using it was that there seemed to be a preferred paradigm of buffering output, then sending that output according to a specific event timer (text_to_buffer()) is the function Socketmud uses for that, if I recall. I personally moved away from that particular option; I have input sent right away via text_to_socket(). Although, it's possible that somewhere along the way it's still buffering or going according to ticks even in that method - I'd have to double-check it to be sure.
27 Aug, 2008, David Haley wrote in the 30th comment:
Votes: 0
There are others, having to do with handling unusual situations – things that are errors or just hiccups in the network. For instance, occasionally a socket will tell you "can't write now, try again later" – this isn't an error, but it is an exception of sorts. I don't know if the FUSS code handles this gracefully; the version of SMAUG I looked at a while ago didn't really do a great job.

As a general design principle, the network code should be as decoupled from the rest of the code as possible. It should be viewed as something that shuttles bytes to and from a remote peer, not as something that enforces various game policies. It's pretty hard to "fix" this in SMAUG, though, because a lot of the pieces are fairly tightly integrated.

I haven't looked at stock networking code for a very long time now, so I'm afraid I can't give more specifics without refreshing my memory of the code. But these are the general kind of problem I found in the past.
27 Aug, 2008, David Haley wrote in the 31st comment:
Votes: 0
In reply to your edit: it can be dangerous to not buffer anything, due to the case I mentioned where the OS will tell you that a socket can't be written to just now. You still need to buffer on your end for circumstances like that.
27 Aug, 2008, Lobotomy wrote in the 32nd comment:
Votes: 0
I suppose that in light of that, rewriting the network code is inevitable. I say so because I'm now going to have to do a detailed examination of said code so that I know what's going on, and so far every such endeavor to re-examine any stock Socketmud code, as well as my own code (in the case of revisiting my code that I had released, much of which is having to be redone for the next version), has resulted in revisions or recreations of some sort.

Oh well. I appreciate the information. It gives me a relative idea of what I should be looking for now. :thinking:
20.0/32