---

new: released unmanaged c++ library! download from my plugins website.
new: 1.2.1 bugfix; mouse_p2p example works. UDP works! everything works
new2: version 1.2.0 released! runtime startcrashs finally resolved! read change-log for further info.


Hi all!

I already announced in the DLL Talk that I had just recently made this easy to use and free Plugin. I would like to present the Plugin now in this Thread, as it might get more attention.

For the originial post go here: http://forum.thegamecreators.com/?m=forum_view&t=73268&b=18
There you will find some benefits about the plugin. You won't be able to answer there though, since it is locked.
The plugin is now in a real safe and secure state, and can be used and tested by you! That's why I actually want your attention; I'd like you to use and test it! As for now I don't see any bugs!

Features
- TCP & UDP support
- 16000+ simultanuous connections (depends on machine)
- new commands allow easy packet management
- allows direct access to packet data
- allows packet creation using memblock
- extended debug information using the debug dll
- faster execution time with the release dll (available on demand)
- extended documentation and help for every single command in there!
- 6 examples
- 1 Tutorial so far

The plugin has 60+ commands so far and is fully documented. You can access the help files with F1 if your editing cursor is above a winsock command. All the commands start with "WINSOCK" to better keep them clustered. There are two server-clients examples included in the help directory, which should help you get started.
The chat server & client is easier to begin with, as it uses the easy command: WINSOCK SEND STRING
If you want to get more advanced, then have a look at the other server&client example included, where you can send packets that you made up in a memblock or memory location.

If you feel stuck read the help files, they might help you get along with the basic errors! And look at the examples in help/examples. Otherwise feel free to post here.


Website
I have put up a website where you find all stuff and links related to my plugins!
http://homepage.swissonline.ch/barnski/main.htm

Download
I have introduced a 3digit version number now.
format: a.b.c
where c is incremented for bugfixes, b for new functions, and a if I extend the dll significantly. I start with 1.0.0!
grab the files from my website (link just above).
read the license agreement please
Note: the debug version is included per default. it shows error messages if you wrongly use the dll. if you want the release dll (faster and smaller in size) ask me.


Online Help
View the full command help list. In the download there are additionally some examples included.
http://homepage.swissonline.ch/barnski/help/winsock.htm

Tutorials
Beginners
The Basics about Winsock http://homepage.swissonline.ch/barnski/Winsock-Basics.html

Oh and before I forget, here's a screenshot of the Chat server & 3 clients in action:


Here is a screenshot of the mouse_p2p UDP example in action:


That's all for now!

---

Thank you thank you very much ive been looking for another multiplayer plugin that might suit me so ill be testing this out and see if its good. I appreciate anyone who takes the time to make a dll for dbpro.

---

This is very good and a significant contribution to the DBP community! Thanks very much!

---

mayby change example code little

+ Code Snippet

disable escapekey    ` <------- this line at first 

do
 remstart
  you code here
 
 remend
 if escapekey() then exit   
loop

while (not escapekey()) not work correct

i use u6.0b2

---

Thanks for the comments!

Is this "not" bug already reported?
Anyways, I changed the example code in all files to what you posted Humanoid.

next thing I will work on is a little UDP example using memblocks.

---

Great memblock example interesting, i dont know is 'not' bug report yet. maybe.

---

So does the server always have to listen for connections??

---

Usually the server sets one channel into the listen mode (before the main loop), and continues with its execution. In the main loop he will check if the listen channel has received a connection request. If so, then it will create a new channel that will handle the connection. The listen channel will remain open and continue listening for connections. But of course you may close it whenever you want, or open several channels that listen on several ports for con.requests!

I might make a tutorial soon that will cover the basics of winsock connections... it will include server/client and peer2peer networking methods. Stay tuned!

---

usually, thats what a server does

---

Okay I promised a tutorial:
http://homepage.swissonline.ch/barnski/Winsock-Basics.html
This one is a short and general discussion about Winsock, meant for those who want to learn about it. The next one will be more specific about my Plugin.


@CattleRustler
I've been thinking of supporting your EZserver with some integrated commands, since it would be great for developers to concentrate on the client, and getting the server for free. While your server provides functionality that will suffice in most cases, it will probably only be helpful for beginners, who use the string commands to send packets (I do not expect advanced users to use string commands, as you can pack much more data using direct memory access/memblocks, and therefore reduce the bandwidth enourmously). Maybe you want to improve your server to handle binary data? instead of using seperators you could use a length indicator.. it would really improve the functionality.

---

Thanks, yes, this was the plan all along (to not rely soley on strings) but I just havent had the time. I have in the past tried to provide a client dll for dbp which would handle all of the parsing etc, but since I dont code in c++ it never came to fruition. In fact the dll was done, handling all features of EZS, and doing remote client management internally in the dll - problem was that the conversion methods to get the .NET dll into usable dbp plugin form was not reliable so I scrapped the project. There have been recent developments that may make these concepts viable again - you and I should talk. Have msn or irc?

---

Hmm I tried it out and it seems more complex to use than it should be...cant you simplify it down to send dword or send integer etc commands because all the other dlls do it? Your average programmer isnt going to want to mess around with memory and rading all sorts of values just to get a little bit of data.

---

I have been thinking about how to simplify the usage... Don't fear: at the end of this week I will have implemented a whole new bunch of commands to acquire this task!

I added you on MSN and sent you an email!

---

okies, ill be on msn later today

---

This is very impressive,Barnski.

Barnski && Cattlerustler
Question or request. Is there or could you implement options to switch on and off TCP Flags like SYN/ACK,PSH,URG,FIN,RST

Ive written basic IDS tools in perl for training purposes.
I'd love to write one in DBP using BlueGUI for a frontend and your sockets plugin,just to show that DBP is very capable of doing far more than just game development.

example perl code(this code has been edited to prevent anyone for trying to cause any damage with it):

+ Code Snippet

#NetPacket::Ethernet to allow for encoding/decoding of 802.3 
#!/usr/bin/perl

print<<__MENU;
                     
                            Packet Craft 
                             
                          written by: x1b
                      
                      
                      
                       hit [enter] when ready

__MENU
<>;

use strict;
use warnings;
use Net::RawIP;
use Net::PcapUtils;
use Net::Divert;
use NetPacket::Ethernet qw(:strip);
use NetPacket::TCP;
use NetPacket::IP qw(:strip :flags IP_PROTO_TCP);

my ($tcp,$ip,$saddr,$daddr,$src_port,$dest_port,$seq,$ack_seq,
$data,$packet,$pkts,$pkt,$delay$ack,$syn,$rst,$fin,$psh,$urg);

if($>!=0)
{
 die "EUID 0 Requirednn";
}


#set source & port addresses
print qq(Source Address: );
 chomp($saddr=<stdin>);
print qq(Source Port: );
 chomp($src_port=<stdin>);
 
print "n";

#set destination and port addresses
print qq(Destination Address: );
 chomp($daddr=<stdin>);
print qq(Destination Port: );
 chomp($dest_port=<stdin>);
 
print "n";

#set flags
print qq(Syn(syn cookie): );
 chomp($syn=<stdin>);
print qq(Ack(acknowledge): );
 chomp($ack=<stdin>);
print qq(Rst(reset): );
 chomp($rst=<stdin>);
print qq(Fin(finish): );
 chomp($fin=<stdin>);
print qq(Psh(push): );
 chomp($psh=<stdin>);
print qq(Urg(urgent): );
 chomp($urg=<stdin>);

print "n";

#set Seq & AckSeq
print qq(Sequence #: );
 chomp($seq=<stdin>);
print qq(Acknowledge Sequence #: );
 chomp($ack_seq=<stdin>);

print "n"; 

#ascii data to wrap in packet
print qq(payload: );
 chomp($data=<stdin>);

#packet count & delay
print qq(number of packets: );
 chomp($pkts=<stdin>);
print qq(packet delay: );
 chomp($delay=<stdin>);

#build new packet  
$packet = new Net::RawIP;
$packet->set({

# set the source to destination addresses in the Internet Protocol
ip => {
saddr => "$saddr",
daddr => "$daddr"
       },

#set flags in the Transmission Control Protocol packet
tcp => {
source => "$src_port", dest => "$dest_port",
ack => $ack,
syn => $syn,
rst => $rst,
fin => $fin,
psh => $psh,
urg => $urg,
seq => $seq, ack_seq => $ack_seq,
data => "$data"}});

#packet delay & packet count
$packet->send($delay,$pkts);

#set nic promisc mode & sniff
Net::PcapUtils::loop(&sniffer,
                    promisc => 1,
                    filter  => 'tcp',
                    dev     => 'eth0');

#tcp sniffer
print "initiating x1bsniffer v0.1nn";
sub sniffer
{
my ($args,$header,$packet) = @_;
$saddr = NetPacket::IP->decode(eth_strip($packet));
 $tcp = NetPacket::TCP->decode($saddr->{data});
$daddr = NetPacket::IP->decode(eth_strip($packet));
 $tcp = NetPacket::TCP->decode($daddr->{data});

print "src: $saddr->{src_ip}:$tcp->{src_port} -> dst: $daddr->{dest_ip}:$tcp->{dest_port}n";
}

---

I have a question. Can this plugin work alongside other plugins such as multisync?

---

Ok thanks thats a releif heh

---

Thanks, though I think I can't follow your request. I ve been spending time yesterday to find out how to set TCP flags on packets, but I think there is no way to do so. You know I am using Winsock's TCP protocol, that means Winsock makes up the IP and TCP header. Then all I add is the packet data.. the body. There is no way to change the TCP header in that way.
I could send OOB (out-of-bound) data, but I am not sure if that is what you wanted. Setting TCP flags manually results nearly in the same as coding the whole TCP protocol (unless you want to make DoS attacks).

I am not quite sure what you are asking for, I see 3 interpretations of your question:
1. can a dbp program that uses your new winsock plugin communicate with another dbp program that uses another winsock plugin?
-Yes, since my Plugin allows you to access and change all the packet data (while soon providind some easier functions).
2. can I have both winsock plugins in the user-plugins folder of my compiler, and then only use one in my code?
-Yes, I think so. Since the compiler wont link the dll that is not used.
3. Can I use both plugin commands in my code?
-No, I don't think so, and besides, I do not see a reason why to do so. But maybe it works, I am not sure how winsock will react to this (you cannot mix connection commands of course, say, connect with my plugin, and then use anothers plugin to send data on that connection).


Now for the new commands I am planing, here is a sketch of their functionality. Tell me if you don't like somethin.

new send commands:
+ Code Snippet

winsock make packet --- will advice the dll to initialize a new packet.
winsock add byte (a_byte) --- 1 byte (character) - in dbp: integer 0-255
winsock add word (a_word) --- 2 bytes (short integer) - in dbp: integer 0-65535
winsock add int (an_int) --- 4 bytes - normal signed integer
winsock add float (a_float) --- 4 bytes - normal float
winsock add string (a_string) --- x+1 bytes, where x is the length of the string.
winsock send packet (a_channel) --- sends the packet on that channel

new receive commands (read commands move read cursor):
+ Code Snippet

winsock split data (a_channel) --- splits the received data into packets (after haveing called winsock recv message, needs data to be sent using the "winsock send packet" command).
winsock fetch packet (a_channel) --- tells the dll to work on this first packet on that channel now.
integer = winsock packet len() --- tells you the length of this packet in bytes.
integer = winsock read byte() --- reads a byte of the packet.
integer = winsock read word() --- reads two bytes of the packet.
integer = winsock read int() --- reads 4 bytes of the packet.
float = winsock read float() --- reads 4 bytes of the packet.
string = winsock read string() --- reads x+1 bytes of the packet, where x is the length of the string.

integer = winsock packet count(a_channel) --- will show the amount of UNREAD packets. read packets will vanish, so you would fetch packets until this command returns 0.

Some more might be added, as I see the need for...

Ok, I think that these commands represent the way how you should work with packets. In every packet you will first want to write a byte or two (using the new commands) to specify the type of the packet, so that the receiver (your other program) will be able to identify the packet and know what to do with it/ what data to read from it.

edit: so a sample code to receive data in a program would look like this:
+ Code Snippet

WINSOCK REFRESH CHANNEL my_channel
if WINSOCK CHANNEL DATA WAITING(my_channel)
  WINSOCK RECV MESSAGE my_channel
  WINSOCK SPLIT DATA my_channel
  while (WINSOCK PACKET COUNT(my_channel) > 0)
    WINSOCK FETCH PACKET my_channel
    `now we can read data
    packet_type = WINSOCK READ BYTE()
  endwhile
endif

---

No. Was hoping to write an app that would allow one to craft a tcp packet (as displayed in my perl code) then set the source and destination addresses in the headers to emulate a Blind Spoof.

Just would have been a new type of app for DBP. I do appreciate that you even took the time to entertain the idea. Thanks Barnski.

---

Ok guys, I did it. I implemented a whole new bunch of commands, documented them as usual with the html help, and tested them with my new example I have added to the download pack. You can see a new screenshot in the first post. It's a Peer2Peer UDP example that transfers ones Mouse coordinates and draws points... as you can see from the screenshot I had my fun

here the list of 20 new commands:
+ Code Snippet

WINSOCK MAKE PACKET : WINSOCK MAKE PACKET
WINSOCK ADD BYTE : WINSOCK ADD BYTE a_byte as Byte
WINSOCK ADD WORD : WINSOCK ADD WORD a_word as Word
WINSOCK ADD DWORD : WINSOCK ADD DWORD a_dword as Dword
WINSOCK ADD INT : WINSOCK ADD INT an_int as Integer
WINSOCK ADD FLOAT : WINSOCK ADD FLOAT a_float as Float
WINSOCK ADD STRING : WINSOCK ADD STRING a_string as String
WINSOCK SEND TCP PACKET : WINSOCK SEND TCP PACKET connected_tcp_channel as Dword
WINSOCK SEND UDP PACKET : WINSOCK SEND UDP PACKET udp_channel as Dword
WINSOCK SPLIT DATA : WINSOCK SPLIT DATA channel_with_data as Dword
WINSOCK PACKET COUNT : Return Integer=WINSOCK PACKET COUNT(channel as Dword)
WINSOCK FETCH PACKET : WINSOCK FETCH PACKET channel_with_packets as Dword
WINSOCK PACKET LEN : Return Integer=WINSOCK PACKET LEN()
WINSOCK READ BYTE : Return Byte=WINSOCK READ BYTE()
WINSOCK READ WORD : Return Word=WINSOCK READ WORD()
WINSOCK READ DWORD : Return Dword=WINSOCK READ DWORD()
WINSOCK READ INT : Return Integer=WINSOCK READ INT()
WINSOCK READ FLOAT : Return Float=WINSOCK READ FLOAT()
WINSOCK READ STRING$ : Return String=WINSOCK READ STRING$()

WINSOCK RESET ERROR --- resets a channel error, used for UDP (see my example).

Oh and I updated the online (the really online) help. You can access it in my first post. You can click on each command to get full help. Maybe this helps deciding whether to download my Plugin or not. Of course the same help and all examples and even the tutorials are included in the download pack.

---

Working from the examples, etc, I've noticed that I can't specify a specific address to bind a listening socket/channel to. Creating a listening UDP socket seems to default to 127.0.0.1, which isn't too useful for receiving remote data. Am I correct in my guess that you test these locally on the same machine? Could you modify 'create udp channel' to listen to '0.0.0.0' by default, and/or accept a parameter to specific the specific address to open the channel on? A machine with multiple network interfaces and addresses could then specify which specific address to listen with.

This is the only caveat I've run into so far, nice work. =)

---

Thanx Heartless.

I just released a new version, where you can optionally specify a local host adress, and it defaults to "0.0.0.0" now.

If you specify a local host adress of "127.0.0.1" or "localhost", then your server will be only accessible from your machine.

If you specify your LAN-address, then your server will only be accessible from within the LAN.

If you don't specify or explicitly set it to "0.0.0.0", then your server should be accessible from anywhere.

If you specify your internet-address (IP), then it will only be acessible over the internet (I think). This may not be possible though if you are behind a router (because your machine has a LAN-ip).

Along with that I fixed some minor issues, and, I made the command "WINSOCK DELETE CHANNEL" to be executed in constant time. unlike the DBPro object deletion commands, this command now deletes a channel equally fast even if you have thousands of them.
However, if you d like to delete all channels, you might just want to use WINSOCK MAKE again to reinitialize winsock (and automatically delete all channels before that).

I hope you can test my plugin again, especially my examples, as I only did test the server.dba and client.dba.
I have not tested the UDP example with my new changes, and nor did I test it over the internet.
If anyone could do this and report whether it works, that would be great.

I think it should work now

edit; when creating an UDP channel, it is not bound to anything! You have to specifically use the WINSOCK BIND CHANNEL command to bind it. This is optional because a client does not need to bind it to a port, only the server. If it should turn out that it does not work over the internet, please notify me

---

Actually, localhost will only allow connections on the same computer, because it doesn't go through any network interface.

---

lol thanx benjamin, it must be the exam I am writing in an hour that confused me

I will edit this now, since it is meant as a reference.

---

Great plugin!
By the way, can I send packets/establish a connection with the client using the native commands to a server using the dll?

---

@Dextro

The native commands in DBPro use DirectPlay.
Because the DirectPlay protocol is layered on top of the UDP protocol, it would theoretically be possible to use my plugin to communicate with directplay. However, I would not recommend you to investigate into this any further, since it just doesn't make sense. It's like forcing a sphere in a hexagonal cylinder...

I suggest you use my winsock plugin exclusively, as it replaces all the native dbpro commands (if ur missing something, tell me), and allows you to go even further.
I do understand though that the big amount of commands in my plugin threaten most people... but the clear benefit of it is the power you get over the networking, and, you are in full control of things.
You just may need to dive into the materia, and learn abit first about winsock, but it will surely pay off, since what you learn using my plugin will be generally valid for networking altogether.

---

Thanks for your reply.
I have some experience with winsock, used with visual basic; but my main concern is about using memblocks with your plugin.
As far as I understand, you can create a "memblock" packet with the WINSOCK ADD XXX command, and send it with WINSOCK SEND TCP PACKET, but what I could not understand, is how you recieve them and read them.
Perhaps you could shed some light into this topic?
Again, thanks for your help, and thanks for the plugin.

---

That's not too complicated:

Packet creation
1. make the packet
2. fill the packet with your bytes
3. send the packet

Packet receival
1. recv message (allows channel to store the data)
2. split data into packets
3. while packet count()>0 do...
4. fetch packet (removes first packet from list and you will now operate on this packet)
5. get the bytes in the packet.
6. return to step 3 if packet count()>0


to see the specific commands in action, you can have a look in my mouse udp example (just replace the WINSOCK SEND UDP PACKET with WINSOCK SEND TCP PACKET)

As soon as I have more time (currently I am working on my Lua Plugin), I think I will write another tutorial. But I hope this brief summary helps to get you started!

---

sorry, couldn't find a link to your mouse udp example, so my question is, what if my message is larger than 255 bytes?
As far as i understand, split data will split my message into 255 byte packets, so let's suppose i send a message structured as 100 floats, 2 words and 1 byte, how would I read them if they are splitted?
Thanks again and sorry for my dumb questions.

---

@Dextro
Your questions are not dump at all. This is indeed a draw back when using the integrated commands. The reason for the packet length to be limited to 255 bytes is that every packet will have a length indicator stored in ONE byte, and therefore this value can not be larger than 255. I decided to do so because MOST packets do not require a more space. therefore a length indicator of 2 bytes would be a waste of bandwith in most of the cases! (I am thinkin of a MMORPG server now, as I always did when designing this plugin, where speed and bandwidth is a crucial thing)

Now this limit is actually no limit at all. If you happen to have to send a longer packet, then just split it into two different ones by your self! You will see that this is a rather rare case, e.g. when transmiting a player's character information upon login.

However, with my plugin you can code your own "packet" setup, by avoiding the packets command and using the other: WINSOCK SEND MESSAGE. With that command, my plugin will not send ANY other information than what you specify. Keep in mind though that you cannot mix these two sending ways!

edit: The examples can be found in the download pack: help\examples\winsock\

---

Alright, so let me get this straight.
If send a "message" consisting of 7650 bytes, it will be fragmented into 30 packets?
Also, if i send a packet of, lets say, 3000 bytes, it would be splitted into 11 packets of length 255, plus 1 of 195 bytes? Or all the packets will be of the same length?
Lets suppose I send a message with a length of 64 floats, which is equal to 256 bytes, How would I read the last float in the message?
Wouldn't it be fragmented?

---

It is not fragmenting it automatically for you. If you add more bytes than 255 to a packet it will cause an assertion (error message), when using the debug dll I provide.

But lets assume you want to make file transfer, then you will definetly not use the packet commands, but my other ones! WINSOCK SEND MESSAGE lets you send up to 8192 bytes at once.

I haven't tried file transfer yet to garantuee that it works nicely. So I will perhaps test this and make an example.


So back to your question: if you want to send a "message" consisting of 7650 bytes, and want to use the packet commands (you have to decide which commands you use for a connection, because you cannot mix them), then you have to manually split it up into 30 packets, each packet's first byte having an apropriate header byte, indicating what packet type we are dealing with...


Actually, fragmentation which you are talking of, is a serious problem, when it comes to overflowing the receive buffer of a channel. the receive buffer grabs up to 8192 bytes, but if, for any reason, there is waiting more, then it will fragment the last packet. THIS is a problem because I haven't taken measures to prevent this.
Normally this will not occurr (as an excuse I could say you need to program your connection better), but in the long term it is best if I add a mechanism to make sure fragmentation is impossible.

I will see how soon I can address this.

---

Thanks for your response, but I'm all confused lol. I guess this is what I get for programming with python.
Ok, so I can receive a message of over 8192 bytes, and I can read it without splitting the packet using WINSOCK BYTE for example?

---

Nope winsock read byte is only for usage in cnojunction with the packet commands.

To read the data directly you have to access the memory directly.

WINSOCK RECV MESSAGE (channel)

ptr as DWORD
an_integer as Integer

ptr = WINSOCK CHANNEL DATA PTR(channel)

an_integer = *ptr
inc ptr, 4
an_integer2 = *ptr
...

edit or, on a byte per byte base:

a_byte as BYTE

a_byte = *ptr
inc ptr, 1
a_byte2 = *ptr
...

This is direct memory access... and you may not exceed the data len: WINSOCK CHANNEL DATA LEN. else you could cause a segmentation fault. I may be making it possible to make a memblock to copy the bytes in....
but at the moment I am not having much time. this week Im writing 2 exams, and after that I plan to go on holidays

but we will see...

Oh and.. there is a new update. make sure to download the new version, instead of getting the one in your web browser cache.

---

Thanks again for your response.
As time passes, more questions arrive, and i have a handful of them right here
Well, first, what is a channel? (sorry for this dumb question, but I'm used to program network stuff with python, and to tell you the truth, I haven't seen that term before. I make mostly hacks and buffer overflows to test our own software.)
As I understand it, I need to use the udp protocol for most of the multiplayer-type games. What I don't understand clrearly is how do I send a message to a specific ip address? What if i want to send it to all the clients at once? Would I have to use a for loop SEND UDP MESSAGE client, ptr, len?
Second, to use the set channel target, i need to know the hostname of the client I need to send it to. That means that first I have to listen on a TCP server, when the client connects pass it's hostname and port to a variable, close the tcp connection, connect client to udp server, ... then set target channel (random channel), variable, variable2?
I guess i have all this questions 'cause i don't know what a channel is, lol.
Sorry for all the questions, but I'm pretty interested in this plugin,
Thanks again,
Billy.

---

Have you read my tutorial about the basics of winsock? there I explain briefly what a channel is. you can find it either in my first post above, or in the download->help folder.

If you want to send a udp message to all clients at once (usually the server needs to do this), then you have to make a for loop, as you said.

When a udp message arrives, it holds automatically the address of its sender. so you can just reply to it (you don't need to call SET CHANNEL TARGET). so there is no problem for peer2peer udp (see my mouse example).


However, it seems that you just found something I haven't thought about yet. if you make a UDP server, then you need to get the remote address into a variable, because the server uses only 1 UDP channel for n clients. that means you have to set the channel target before sending things. But I need to investigate further into this. Me personally, I have only used TCP server/client so far. I never made a UDP server and haven't thought about the issues that arrise . its more complex than a TCP server actually.

so I will add a function that allows you to get the senders host address.
And I will recheck UDP functionality.

edit;
I think the UDP socket (channel) works like this:
when you call recv message, then only a message from one sender will be returned. and after that you should retreive the remote hostaddress. then check whether there is more data waiting, and repeat the same...

---

please make this dbc compatible

---

I don't have DBC nor do I know what to do to make it compatible.

But if DBC is able to load a dll and call dll functions, then you can just use this string table to find out the names of the functions.

syntax of string table entries:
DBP_name % arguments % DLL_FUNCTION_NAME % description_of_arguments

You need the DLL_FUNCTION_NAME part to call the function directly.
use the description of arguments or the help to find out which arguments are needed.

here is the table:
+ Code Snippet

/////////////////////////////////////////////////////////////////////////////
//
// String Table
//

STRINGTABLE 
BEGIN
    IDS_STRING101           "WINSOCK MAKE%0%make"
    IDS_STRING102           "WINSOCK ERROR[%L%get_error"
    IDS_STRING103           "WINSOCK ERROR NR[%L%get_error_nr"
    IDS_STRING104           "WINSOCK ERROR MSG$[%S%get_error_msg"
    IDS_STRING105           "WINSOCK CHANNEL ERROR[%LD%get_channel_error%channel"
    IDS_STRING106           "WINSOCK CHANNEL ERROR NR[%LD%get_channel_error_nr%channel"
    IDS_STRING107           "WINSOCK CHANNEL ERROR MSG$[%SD%get_channel_error_msg%channel"
    IDS_STRING108           "WINSOCK REFRESH CHANNEL%D%refresh_channel%channel"
    IDS_STRING109           "WINSOCK REFRESH CHANNELS%0%refresh_channels"
    IDS_STRING110           "WINSOCK LISTEN[%DL%listen_on%local_port"
    IDS_STRING111           "WINSOCK CONNECT[%DSL%connect_to%host_name, host_port"
END

STRINGTABLE 
BEGIN
    IDS_STRING112           "WINSOCK CREATE UDP CHANNEL[%D%create_udp_channel"
    IDS_STRING113           "WINSOCK SEND MESSAGE%DDL%send_message%tcp_channel, data_ptr, data_len"
    IDS_STRING114           "WINSOCK RECV MESSAGE%D%recv_message%tcp_channel"
    IDS_STRING115           "WINSOCK DISCONNECT%D%disconnect%open_tcp_channel"
    IDS_STRING116           "WINSOCK RECONNECT%D%reconnect%disconnected_tcp_channel"
    IDS_STRING117           "WINSOCK DELETE CHANNEL%D%delete_channel%disconnected_channel"
    IDS_STRING118           "WINSOCK SEND UDP MESSAGE%DDL%send_udp_message%udp_channel, data_ptr, data_len"
    IDS_STRING119           "WINSOCK RECV UDP MESSAGE%D%recv_udp_message%udp_channel"
    IDS_STRING120           "WINSOCK SET CHANNEL TARGET%DSL%set_channel_target%disconnected_channel, host_name, host_port"
    IDS_STRING121           "WINSOCK CLEAN UP%0%clean_up"
    IDS_STRING122           "WINSOCK BIND CHANNEL%DL%bind_channel%disconnected_channel, local_port"
    IDS_STRING123           "WINSOCK ACCEPT[%DD%accept_connection%listen_channel"
    IDS_STRING124           "WINSOCK CHANNEL DATA WAITING[%LD%channel_data_waiting%channel"
    IDS_STRING125           "WINSOCK CHANNEL DATA PTR[%DD%channel_data%channel"
    IDS_STRING126           "WINSOCK CHANNEL DATA LEN[%LD%channel_data_len%channel"
    IDS_STRING127           "WINSOCK SEND STRING%DS%send_string%tcp_channel as Dword, message as String"
END

STRINGTABLE 
BEGIN
    IDS_STRING128           "WINSOCK RECV STRING[%SD%recv_string%tcp_channel as Dword"
    IDS_STRING129           "WINSOCK MAKE%LL%?make@@YAXHH@Z%int major_version, int minor_version"
    IDS_STRING130           "WINSOCK MAKE PACKET%0%make_packet"
    IDS_STRING131           "WINSOCK ADD BYTE%D%add_byte%a_byte as Integer"
    IDS_STRING132           "WINSOCK ADD WORD%D%add_word%a_word as Integer"
    IDS_STRING133           "WINSOCK ADD INT%L%add_int%an_int as Integer"
    IDS_STRING134           "WINSOCK ADD FLOAT%F%add_float%a_float as Float"
    IDS_STRING135           "WINSOCK ADD STRING%S%add_string%a_string as String"
    IDS_STRING136           "WINSOCK SEND TCP PACKET%D%send_tcp_packet%connected_tcp_channel as Dword"
    IDS_STRING137           "WINSOCK SEND UDP PACKET%D%send_udp_packet%udp_channel as Dword"
    IDS_STRING138           "WINSOCK SPLIT DATA%D%split_data%channel as Dword"
    IDS_STRING139           "WINSOCK PACKET COUNT[%LD%packet_count%channel as Dword"
    IDS_STRING140           "WINSOCK FETCH PACKET%D%fetch_packet%channel as Dword"
    IDS_STRING141           "WINSOCK PACKET LEN[%L%packet_len"
    IDS_STRING142           "WINSOCK READ BYTE[%D%read_byte"
    IDS_STRING143           "WINSOCK READ WORD[%D%read_word"
END

STRINGTABLE 
BEGIN
    IDS_STRING144           "WINSOCK READ INT[%L%read_int"
    IDS_STRING145           "WINSOCK READ DWORD[%D%read_dword"
    IDS_STRING146           "WINSOCK READ FLOAT[%F%read_float"
    IDS_STRING147           "WINSOCK READ STRING$[%S%read_string"
    IDS_STRING148           "WINSOCK ADD DWORD%D%add_dword%a_dword as Dword"
    IDS_STRING149           "WINSOCK RESET ERROR%D%reset_channel_error%channel as Dword"
    IDS_STRING150           "WINSOCK BIND CHANNEL%DSL%bind_channel_host%disconnected_channel as Dword, local_hostname as String, local_port as Integer"
    IDS_STRING151           "WINSOCK LISTEN[%DSL%listen_on_host%local_hostname as String, local_port as Integer"
END

I hope DBC can load dll's...

---

I hear that. Just got finished writing 29 pages myself.

I'm trying to convert my java program and having some trouble sending data. It might be the way i'm trying to use pointers.
Here's the error I get:
Error in recv_message. recv returned: -1

[edit]
problem with my string length, fixed.
proper length of the expected message is now sent, but server timesout. What I need to send is "FLAPONrnrn", 10 characters. (4 escape characters, )


I'm expecting to receive 10 bytes, and should as long as the string is being sent properly.

I just need to output a string as a series of bytes. If I try to use "WINSOCK SEND STRING", then I don't get any server response.


I believe its to be sent out in big-endian. I'm a java guy, not pointer friendly.

The data to send is correct, as i've got this working in java just fine. Ideas?

+ Code Snippet

#constant TRUE = 1
#constant FALSE = 0

loginServer as string
loginPort as integer
loginServer = "toc.oscar.aol.com"
loginPort = 5190

authServer as string
authPort as integer
authServer = "login.oscar.aol.com"
authPort = 2999


connChannel as dword

rem initialize winsock
winsock make

rem connect to the server
connChannel = winsock connect(loginServer, loginPort)

rem make sure connection was successful
errorChecking(connChannel)

sendSignonFlap(connChannel)


print "press any key to exit"
suspend for key

WINSOCK DISCONNECT connChannel
WINSOCK DELETE CHANNEL connChannel
WINSOCK CLEAN UP


rem
function sendSignonFlap(channel as dword)
   sendData(channel, "FLAPON"+chr$(13)+chr$(10)+chr$(13)+chr$(10))
   TIMEOUT = 5000
   TIMESTAMP as dword
   TIMESTAMP = timer()
   stuff = 0

   rem wait for signon message
   rem should probably throw in a timeout variable
   while stuff = 0
      WINSOCK REFRESH CHANNEL channel
      if (winsock channel data waiting(channel))
         stuff = 1
         WINSOCK RECV MESSAGE channel
         errorChecking(channel)
         dataPtr as dword
         dataPtr = WINSOCK CHANNEL DATA PTR(channel)
         dataLen = WINSOCK CHANNEL DATA LEN(channel)
         print "length: ",dataLen
         m = *dataPtr
         print "message: ",m
      endif
      if timer() >= TIMESTAMP+TIMEOUT
         print "TIMEOUT"
         exitfunction
      endif
   endwhile

endfunction



rem send string as raw bytes over the channel
function sendData(channel as dword, msg as string)

   msgLen = len(msg)
   ptr as dword
   ptr = make memory(msgLen)
   for i=1 to msgLen
      `*ptr = mid$(msg,i)
      `inc ptr, 1
   next i

   *ptr = asc("F") : inc ptr, 1
   *ptr = asc("L") : inc ptr, 1
   *ptr = asc("A") : inc ptr, 1
   *ptr = asc("P") : inc ptr, 1
   *ptr = asc("O") : inc ptr, 1
   *ptr = asc("N") : inc ptr, 1
   *ptr = 13 : inc ptr, 1
   *ptr = 10 : inc ptr, 1
   *ptr = 13 : inc ptr, 1
   *ptr = 10

   winsock send message channel, ptr, 10

   `winsock send message channel, ptr, msgLen

   `WINSOCK SEND STRING channel, msg
   errorChecking(channel)
endfunction


rem checks for channel errors
function errorChecking(channel as dword)
   if WINSOCK CHANNEL ERROR(channel) <> 0 then throwException(WINSOCK CHANNEL ERROR MSG$(channel))
endfunction

rem Prints out error message and exits program
rem after any key press
function throwException(err as string)
   print err
   suspend for key
   end
endfunction

[edit]
it finally hit me, i wasn't resetting the pointer's location back to the beginning. problem fixed.

---

The error you get just indicates a forceful disconnection from the server (server closed connection).
I have changed the error code information, such that it is more informative (-1 is just general socket error, but there is always a more specific code, which I have forgot to add here). But not uploaded yet.

Now to your code and problem:
I read your source but can't find any obviuos mistakes. I will recheck it tomorrow (evening), and try whether it is the way DBP handles pointer assignment.
Besides, it was very nice to read your code, nicely structured and commented! thanx

this does not affect the message data you send. its just the header data that has to be translated from little- to big-endian. but this is done by winsock. (except of course, if your server reads binary data from what you send him, and if he uses a big-endian system) but since you send strings (byte-sequence), it is not necessary to revert anything..

That is strange, since I can't see a reason why my plugin should treat the binary data sequence differently as the string (its the same in memory actually, with the slight difference that the string is 0-terminated, but this 0 will not be transmitted).
It could be that DBPro cuts out the 13 10 13 10 in the string... I will test this tomorrow, and hopefully provide a solution