That all seems like a good idea but theres one small problem with the multi-packet messaging. That is in order to check they're client ID they need to be on your list which has a limit of 250 people I'm not sure how your going to code it if your going to make the protocol add people to the bots list or just make it add it to its RL (reverse list). So making it check for the client ID by having them on the bots list is a bad idea because of the contact-list limit.
UUX is just personal messages beside your name. (exampe: Jerome - this is UUX) - You need the latest build of MSN messenger 7.0.0604 Theres mirrors on mess.be for it. Oh yeah and also in the new MSN it has a msn search built in it.
Code:
MSG <TrID> N <Length>\*lazy*\n<br />MIME-Version: 1.0\*lazy*\n<br />Content-Type: text/search-query\*lazy*\n\*lazy*\n<br />Your search
Oh and also, about the Client IDs what if you wan't (Ink-sending+Ink-receiving+MSNC4) put together? and the client (user) who is using Net::MSN doesn't know how to add them together to get one ClientID (or will you make a document on that?)
Oh oh one more thing. If your going to convert the code to MSNP10 not 11 then theres no point for the ClientID _MSNC4 because MSNC4s client ID requires msnp11 to work. lmao I talk to much eh?
Joined: 19 Jul 2004 Posts: 556 Location: Los Angeles, CA votes: 1
Posted: Tue Feb 22, 2005 3:55 am Post subject:
Hey and welcome to bot-depot. Ive done alot of the p2p work on the msn.pm. My website with my current beta is http://msndev.com, you can also add me to your msn: \[EMAIL=matt@msndev.com\]matt@msndev.com\[/EMAIL\]. I hope we can all work well togrther.
(and yes an offical release with full file transfer is soon, sorry to take so long guys) _________________ [ matt ]
That all seems like a good idea but theres one small problem with the multi-packet messaging. That is in order to check they're client ID they need to be on your list which has a limit of 250 people I'm not sure how your going to code it if your going to make the protocol add people to the bots list or just make it add it to its RL (reverse list). So making it check for the client ID by having them on the bots list is a bad idea because of the contact-list limit.
Well, firstly Net::MSN isnt a bot - its an API to the msn protocol. Other than that I would implement the following.
send_split_messages (TRUE/FALSE) - Default to splitting up messages larger than 1000/1200 bytes (not characters, 'use bytes;')
force_multi_packet_msgs (TRUE/FALSE) - Force sending of multi-packet messages (if there is no client id - if there is a client id and the client doesnt support them dont send mpm)
Obviously it wont be as above - probably alot cleaner, but something along the lines of that - always falling back to splitting the message perhaps.
Quote:
UUX is just personal messages beside your name. (exampe: Jerome - this is UUX) - You need the latest build of MSN messenger 7.0.0604 Theres mirrors on mess.be for it. Oh yeah and also in the new MSN it has a msn search built in it.
Sounds cool
Quote:
Oh and also, about the Client IDs what if you wan't (Ink-sending+Ink-receiving+MSNC4) put together? and the client (user) who is using Net::MSN doesn't know how to add them together to get one ClientID (or will you make a document on that?)
You didnt actually look at ClientID.pm did you?
Code:
<br /> my $client_id = Net::MSN::ClientID->extract( client_id_int );<br /> if ($client_id->msnc4()) {<br /> print "Is MSN 7\n";<br /> }<br /> if ($client_id->have_webcam()) {<br /> print "Has Webcam\n";<br /> }<br /> # e.t.c ...<br /><br /> my $client_id = Net::MSN::ClientID->new(<br /> msnc3 => TRUE,<br /> multi_packet_message => TRUE,<br /> );<br /> print "The ClientID i just made is: ". $client_id->as_int(). "\n";<br /> # prints 805306400<br /><br /> # How does all this fit in?<br /> # Clients own ClientID ... (there are defaults applied when new is called)<br /> $self->client_id( Net::MSN::ClientID->new() );<br /><br /> # then the method change_status uses it<br /> sub change_status {<br /> my ($self, $status) = @_;<br /><br /> return unless ($status);<br /><br /> my $client_id = ($self->client_id()) ?<br /> $self->client_id()->as_int() : 0;<br /><br /> $self->notification()->send('CHG', uc($status). ' '. $client_id);<br /> }<br /><br /> # contact list users ...<br /> my $user = $self->contact()->find_or_create_user($username);<br /> if ($user) {<br /> $user->friendly_name( uri_unescape($friendly_name) );<br /> $user->status_code( $status );<br /> $user->client_id( $client_id ); # Inflated with integer<br /> }<br /><br /> # elsewhere in the code... (client_id is automatically deflated into a ClientID object)<br /> if ($user->client_id()->have_webcam()) {<br /> print "You got a webcam sir!\n";<br /> }<br />
So yeah, it is VERY flexiable ability to both create and parse (extract) Client ID's - the BV_ constants mentioned before are used in the 'as_int()' method to 'add up' the client id - and in the 'extract()' method to 'Bitwise AND' calculate the values for the accessors.
Quote:
Oh oh one more thing. If your going to convert the code to MSNP10 not 11 then theres no point for the ClientID _MSNC4 because MSNC4s client ID requires msnp11 to work. lmao I talk to much eh?
Never hurts to have something there like that that you arent using just yet - it makes your code more future proof / documented for when you may actually need it.
Ah, I see. I thought you were going to make user choose what clientID they wanted to use as a feature. Anyways in the tar file you posted doesn't have Net::MSN::ClientID so I really couldn't check it :-/
or something like that, on that note i really want to rename 'sendmsg' to 'send_message' since its the only command without a _ to join the words
Of course none of the above is implemented, but all that would be needed to implement it would be for me to define SEARCH_MSG, currently DEFAULT_MSG is a constant (template) for a normal message
Well if you make it a fast way of doing it Yep. But you wouldn't use send_msg since when you send the data to that socket it sends a send_msg command already.
soo it's just:
Code:
sub send_search_msg {<br />my ($client, $search_string) = (shift, shift);<br /><br />$message = Net::MSN::Message->new(<br /> header => SEARCH_MSG,<br /> body => $search_string,<br /> );<br /><br />$client->send($message); # Or wtv you use to send data.<br />}<br /><br />$client->send_search_msg($search_string);
What i mean is currently I have 'sendmsg' in (Net::)MSN.pm, which tries to send a message to the 'active' (last typed in by user) or 'most recent' (highest connection(file no)) SwitchBoard - if there is none, it places a call and puts the message in a queue to be sent once its connected fully - During this there is a 'pending_switchboard' tracking system which of course queues more messages that may have been sent while actually trying to get a switchboard ready - what that all means is I can for (1..100) { $client->sendmsg(' test 1 ') } and they will ALL go through - im quite suprised it doesnt disconnect me.. hehe
I also have 'sendmsg_private' which will try and track down a private (only the client and the user, no one else) SwitchBoard to send a message - otherwise it will call the user.
If there was a 'send_search_message' method it of course would call a method for sending a MSG to the ns server - i assume thats where it goes.
And what i meant is id like to rename 'sendmsg' to 'send_message' - as in the method in my module .. and also 'sendmsg_private' to 'send_message_pvt'.. or something.
Well firstly - Hi all, im glad this place is back up and running. I have a question for any MSN protocol wiz's..
Does anyone know a way of ensuring that my client recieves the messages right away?
What I mean is, sometimes i'll send a message via my messenger, and it wont arrive untill i start tyoing (he then recieves TypingUser messages.. and the message arrives just before them)... Ive also made a simple bot to play scrabble with a friend of mines bot but he never sees the 'ok, the next letters are..' and keeps guessing on the old word for a while.. then they all come through.. its quite annoying. I have tried to turn autoflush on the socket on - but that didnt help.. would it be the switchboard buffering?