This is the small program I've written some time ago and maybe you'll find it nice if I share it ;). It uses winsock with fasm and allows to communicate through selected port using the raw protocol. The upper line of controls allows you to listen for connection on the specified port, the line below allows you to connect to server (write name of server in the "Host name" field and press Enter to get the IP, you'll be automatically moved to "Port" field, write port number there and press Enter to connect), so you can even use this program to connect with its server instance and get some kind of "mini-chat" program.
You can also play with SMTP/POP3/FTP/HTTP protocols using it, and it can be a big fun (RFCs recommended ;)).
You can also play with SMTP/POP3/FTP/HTTP protocols using it, and it can be a big fun (RFCs recommended ;)).
Can't build it with fasmw 1.46
error on:
dialog main,'Quetannon',70,70,332,176,WS_CAPTION+WS_POPUP+WS_SYSMENU+WS_MINIMIZEBOX+DS_MODALFRAME
Invalid argument
Instruction:
data?00039C25 dd or DS_SETFONT,0
PS
Source code still useful =)
error on:
dialog main,'Quetannon',70,70,332,176,WS_CAPTION+WS_POPUP+WS_SYSMENU+WS_MINIMIZEBOX+DS_MODALFRAME
Invalid argument
Instruction:
data?00039C25 dd or DS_SETFONT,0
PS
Source code still useful =)
maksa, do you have the latest includes? Your problem is with new comrade's Dialog MACRO
(included since fasm 1.46.9.1)
Best Regards,
(included since fasm 1.46.9.1)
Best Regards,
no, I don't.
Thanks, I'll download it.
Best wishes.
Thanks, I'll download it.
Best wishes.
Privalov, I like your program, it looks nice and is handy for debugging, but it does have some errors in the code. For example, it lacks error checking after calling send, but even if it succeeds it might not send all the data on a non-blocking socket. If you use non-blocking sockets with window messages, you'll have to handle FD_WRITE and use send's return value.
Thomas
Thomas
Error handling is for pussies.
Great stuff, Privalov!
One thing I don't understand, though, is the following:
For example, FTP servers listen on port 21, but can accept many connections.
Using two Quetannon's, however, I cannot make both listen to the same port, nor I can connect two clients to the same server's port.
Is this a limitation of your excellent small sample app, or an inherent limitation of Windows?
Anyway, once more congratulations for your sample app!
PS: what would be the quickest / least overhead/latency way to build such a server/client pair?
Windows messaging notification possibly adds latency.. is there anything more lowlevel, to know when we received some new data?
When you accept connection, its given some arbitrary port and listen socket still remains open.
Error handling is for pussies.
I hope you were yoking. Not handling errors, assuming they won't occur is bad programming, but not handling send's return value is plain wrong.
When you accept connection, its given some arbitrary port and listen socket still remains open.
No it isn't, it's using the same port number as the listening socket. Port numbers were created to identify a process on the system. A connection is uniquely identified by the pair (client IP+host), (server IP:host), not just by one of those. So it's possible to have multiple connections on the same port.
Thomas
Originally posted by Kyle Katarn
For example, FTP servers listen on port 21, but can accept many connections.
Using two Quetannon's, however, I cannot make both listen to the same port, nor I can connect two clients to the same server's port.
Is this a limitation of your excellent small sample app, or an inherent limitation of Windows?
For example, FTP servers listen on port 21, but can accept many connections.
Using two Quetannon's, however, I cannot make both listen to the same port, nor I can connect two clients to the same server's port.
Is this a limitation of your excellent small sample app, or an inherent limitation of Windows?
It's a limitation of TCP/IP. Imagine you would have two different processes listening on port 21. Then a package comes in addressed at your IP and port 21. How should windows (or any TCP/IP implementation for that matter) know to which process it should forward it?
PS: what would be the quickest / least overhead/latency way to build such a server/client pair?
Windows messaging notification possibly adds latency.. is there anything more lowlevel, to know when we received some new data?
Windows messaging notification possibly adds latency.. is there anything more lowlevel, to know when we received some new data?
There are many I/O models you can use, see my site for an overview of them.
Thomas
I hope you were yoking. Not handling errors, assuming they won't occur is bad programming, but not handling send's return value is plain wrong.
No it isn't, it's using the same port number as the listening socket. Port numbers were created to identify a process on the system. A connection is uniquely identified by the pair (client IP+host), (server IP:host), not just by one of those. So it's possible to have multiple connections on the same port.
Thomas
Don't f*ck around with me.
Straight from help file:
This is also from my programming experience, where I could use my original socket that I invoked listen() on to accept more than one connection without reopening.
This function extracts the first connection on the queue of pending connections on s
, creates a new socket with the same properties as s and returns a handle to the new socket. If no pending connections are present on the queue, and the socket is not marked as nonblocking, accept blocks the caller until a connection is present. If the socket is marked nonblocking and no pending connections are present on the queue, accept returns an error as described following. The accepted socket may not be used to accept more connections. The original socket remains open.
, creates a new socket with the same properties as s and returns a handle to the new socket. If no pending connections are present on the queue, and the socket is not marked as nonblocking, accept blocks the caller until a connection is present. If the socket is marked nonblocking and no pending connections are present on the queue, accept returns an error as described following. The accepted socket may not be used to accept more connections. The original socket remains open.
This is also from my programming experience, where I could use my original socket that I invoked listen() on to accept more than one connection without reopening.
pointless arguments are the most entertaining :grin:
to comrade
Please, don't use rude words - control yourself. I like this forum and I realy don't want it become "dirty".
??? ?? ?????, ?? ? ????? ??? ???? ???????? - ??????? ????? ?????????, ?????? ??????, ?? ????? ??? ??????. =)
Please, don't use rude words - control yourself. I like this forum and I realy don't want it become "dirty".
??? ?? ?????, ?? ? ????? ??? ???? ???????? - ??????? ????? ?????????, ?????? ??????, ?? ????? ??? ??????. =)
Don't f*ck around with me.
Calm down :rolleyes:..
Originally posted by comrade"]
Straight from help file:
[...]
This is also from my programming experience, where I could use my original socket that I invoked listen() on to accept more than one connection without reopening.
Straight from help file:
[...]
This is also from my programming experience, where I could use my original socket that I invoked listen() on to accept more than one connection without reopening.
My "no it isn't" applied to "its given some arbitrary port", maybe I should have been more specific about that. Sorry if that caused the misunderstanding. I know the listening socket stays open but you're wrong in saying that the new, accepted socket is given an arbitrary port. The docs also confirm that by saying "This function extracts the first connection on the queue of pending connections on s, creates a new socket with the same properties as s".
Thomas
Thomas: I did not care, because fail on send usually only happens when the connection is lost, and in that case the FD_CLOSE handler just displays the appropriate message. This is just a small example of simple use and so I didn't think it's really necessary to take everything into consideration.
Thomas: I did not care, because fail on send usually only happens when the connection is lost, and in that case the FD_CLOSE handler just displays the appropriate message. This is just a small example of simple use and so I didn't think it's really necessary to take everything into consideration.
Well leaving error checking out may be a choice (a bad one in my opinion though), but send is a special case. Send doesn't just fail in case of a connection loss, it also fails if winsock's buffer is full (WSAEWOULDBLOCK). And even if it succeeds, it might not have sent all the bytes...
It's not very likely that this will happen in your program because the data sent is pretty small (and the nagle algorithm does it's job), but compared to a failing listen (or something), chances are much higher.
The problem with examples is that people often use them as a base for their own applications. So using bad examples result in bad programs. It might not really matter in your app, but if one uses it to write a HTTP request app, it's pretty likely the request will fail if the server can't receive it in at once.
It's your example so do with it what you like, but you really ought to handle at least send's return value.
Thomas
The problem with examples is that people often use them as a base for their own applications. So using bad examples result in bad programs. It might not really matter in your app, but if one uses it to write a HTTP request app, it's pretty likely the request will fail if the server can't receive it in at once.
Yes, you're right.
I'll add some error checking there at the closest occasion.