tonyshowoff
|
> I am currently unsure if that means AOL used pure sockets for AOL communication (at one point) or if AOL did use TCP/IP, and the protocol data was carried over from QL. If it's the former, then I'd imagine having a hard time implementing some kind of alternate server for AOL.
Take a peak at the ZMODEM specifications, consider "Z", the fact it's called a FRAME, CRC, a 1 byte command rather than 2, etc...
Essentially the protocol was developed to work over X.25, but switched to working over TCP/IP, I *think* in AOL 3.0 but they didn't change the protocol, they just pushed it over TCP/IP, to allow "sign on over Internet" or whatever it was, and reverse compatibility going back to earlier versions, or something, I'm not sure it was a little before my time.
|
ohhihohello57
|
lol so AOL borrowed a file transfer protocol and added their own specs to it. Considering it was originally supposed to be sent over X.25, which from what I can tell, doesn't have integrity verification, I'm not that bugged.
"the protocol ... switched to working over TCP/IP, I *think* in AOL 3.0 but they didn't change the protocol, they just pushed it over TCP/IP"
If that's the case, then that's good, as I was actually fighting with that exact version of AOL so that I could build a server out of its protocol and eventually make something tangible out of it. Now I know that I won't be touching AOL 2.0 and below. But there's still trying to convince AOL to connect via my XP VM's internet interface that's hooked onto my laptop's wi-fi. =p
if (Nerd->Personality == (NERD_PERSON_FRONTFACING + NERD_PERSON_SMARTALEC)) { return; }
|
tonyshowoff
|
Well, they didn't borrow it exactly, but it shares a lot of the similarities because it was well designed, but you can find similar things in other protocols of the era, there wasn't a whole hell of a lot of ways to do things with the limitations at hand, the strangest aspect is that they continued on well after there was no chance at all of their DOS or 3.1 based clients connecting. Though AOL 2.5 and AOL 2.7 Mac worked well into the early 2000s, I don't recall exact numbers.
There's also compression of the FDO which I have libraries to decompress and I think there may be ones out there to do it, you'll have to deal with that if you plan on implementing the protocol. A lot of work was offloaded onto FDO.
|
c0n
|
I am late to the party. thats what i get for napping on a hot saturday...
> MySQL though introduces blocking into something which should be non-blocking. AIM used a system separate which reported things like screenname status, kept track of the state of buddies (known as Feedbag), this is opposite of, say, IRC which each server keeps the entire state. This is also why in AIM the authorizer uses a separate system and passes along a "cookie" of auth information.
Did you mean table locking? This can be accomplished without locking, or it could be batched. In Xeon, the web and AIM services need to be separated, at the very least.
which reminds me, I haven't examined the protocol, but when signing-on or AIM, it appears that the protocol does not send the buddies that are online in batches, one by one they appear... seems inefficient.
> I have began trying to email or rather even find the right damn people to email or call to find out if I can
This sounds like you have official code. Did you use to work there? Feel free to ignore this question if you cant answer.
> There's also compression of the FDO
Are we still taking about AIM? AIM uses FDO also? In what?
> iserved
I did google this... throw me a bone :) where/what is iserved? I cant find this documentation.
BOOM!
|
tonyshowoff
|
> Did you mean table locking? This can be accomplished without locking, or it could be batched.
No, socket blocking, but also I/O blocking. Even if you have nonblocking sockets, consider that a given thread (multithreaded or not) makes a request to MySQL, unless you're using MEMORY tables, you'll hold up that entire thread while you look up the details. It's not that apparent with just a few users, but it will exponentially become a problem.
> In Xeon, the web and AIM services need to be separated, at the very least.
Sure, that's always the best route to go.
> it appears that the protocol does not send the buddies that are online in batches, one by one they appear... seems inefficient.
Well, depending on the protocol version you're looking at, you'll either have to add your buddies and the state is returned to you at each sign on, or you'll get a binary state from the feedbag directly of the state of buddies at sign on and any additional information as states change or if the state is unusual, or perhaps it's improperly implemented and doing that when it isn't supposed to, or you're working on a much larger network where the same state server isn't tracking the same buddies. That latter point is why you can't send in batch aside from the initial feedbag dump.
> This sounds like you have official code. Did you use to work there?
I do, and already answered the second part on another post.
> Are we still taking about AIM? AIM uses FDO also? In what?
No, I was talking about the AOL client with the other user.
> I did google this... throw me a bone :) where/what is iserved? I cant find this documentation.
It's "iserverd", don't forget the second "r". It's a Russian guy who was building his own ICQ server. It's ICQ oriented but he did show a lot of AIM protocol information, there's plenty missing from additional foodgroups for obsolete features never made public, some administration, etc.
|
c0n
|
Got it. http://iserverd.khstu.ru/oscar/
great. interesting. Keep us updated on your (hopeful) progress or if you cannot release the code (ugh, that would be so sad) you can give us some hints...
> may or may not have...
ah. dont know how I missed that part at the beginning of the tread. Well this explains a lot. I became a part of the scene in the mid-to-late 90s. I'd love it if you would talk about the "hackor" kids from an AOL point of view. I'm sure you got stories if you were near the department that was dealing with that. The ones that were making the progs which caused a lot of havok (no pun intended) ... did it contribute to teh FATE of AOL? (ok... maybe that was intended) Could you talk a bit about that?
BOOM!
|
tonyshowoff
|
> The ones that were making the progs which caused a lot of havok (no pun intended) ... did it contribute to teh FATE of AOL? (ok... maybe that was intended) Could you talk a bit about that?
I'd suggest for the sanity of the forum you create a new thread based upon those questions.
|
|
![[Reply]](img/forum/topicreply2.png)