On my server, I'm using WSAAccept for incomming connection. How do I validate if connection is coming from a known source? I only want to allow a specific application to connect on my server.
How can I improve this line of code?
Accept = ::WSAAccept( SOCKET_INSTANCE, NULL, NULL, NULL, 0 );
Personally I'd put a function on the client and server that does something complicated with a number input. The server sends the number to the connecting client, then the client plugs it into the function and sends it back to the server, and finally, the server checks it, if it is right it lets the client continue doing stuff, otherwise it drops the connection.
Related
I have a client application that uses IOCP for socket communication. I'm using ConnectEx to make the TCP connection to the remote endpoing (binding the socket to ADDR_ANY and port 0 before calling ConnectEx).
It will be valid to have two connections to the same remote endpoint (same IP address and port number). When I test that condition with my current code, I have two overlapped IO read operations outstanding (one on each connected socket) from calls to WSARecv(). Each WSARecv() is called with the correct socket and overlapped structure. For example: WSARecv(socket1, ... overlapped1) and WSARecv(socket2, ... overlapped2). The problem I've run into is that when I get a response back from either remote, it triggers the completion event for both of the outstanding overlapped operations. My code only produces this result when two remotes have the same ip address and port number, not when there are two unique remote addresses. Is this the expected behavior (hopefully not)? If so, is there another way to accomplish this?
I'm posting an answer, even though it is really just an explanation of why the problem happened.
My test involved connecting to and communicating with a remote device that provides data. It turns out that it is on the other side of a digi terminal server. So the connection path was:
my test computer (via TCP) -> Digi terminal server (via Serial) -> remote device.
The digi terminal server basically converts TCP/IP to serial communications, and back. Since the serial side doesn't have a concept of 'connectedness' the digi doesn't know which TCP/IP connection should receive the serial data in response to a TCP/IP request, so it forwards the serial data to all active connections on the TCP/IP side. That's what was producing the IOCP trigger on both of my pending overlapped operations. Every time a request was sent to the digi, it sent the request out of its serial port. When the end device responded, the digit forwarded the response data to each of my TCP/IP connections.
Thanks to everyone who commented on my question, but sorry for taking up your time.
How come every site explains that in SSE a single connection stays opened between client and server "With SSE, a client sends a standard HTTP request asking for an event stream, and the server responds initially with a standard HTTP response and holds the connection open"
And then, when server decides it can send data to the client while what I am trying to implement SSE I see on fiddler requests being sent every couple of seconds
For me it feels like long polling and not a one single connection kept opened.
Moreover, It is not that the server decides to send data to the client and it sends it but it sends data only when the client sends next request
If i respond with "retry: 10000" even tough something has happened that the server wants to notify right now, will get to the client only on the next request (in 10 seconds from now) which for me does not really looks like connection that is kept opened and server sends data as soon as he wants to
Your server is closing the connection immediately. SSE has a built-in retry function for when the connection is lost, so what you are seeing is:
Client connects to server
Server myteriously dies
Client waits two seconds then auto-reconnects
Server myteriously dies
Client waits two seconds then auto-reconnects
...
To fix the server-side script, you want to go against everything your parents taught you about right and wrong, and deliberately create an infinite loop. So, it will end up looking something like this:
validate user, set up database connection, etc.
while(true){
get next bit of data
send it to client
flush
sleep 2 seconds
}
Where get next bit of data might be polling a DB table for new records since the last poll, or scan a file system directory for new files, etc.
Alternatively, if the server-side process is a long-running data analysis, your script might instead look like this:
validate user, set-up, etc.
while(true){
calculate next 1000 digits of pi
send them to client
flush
}
This assumes that the calculate line takes at least half a second to run; any more frequently and you will start to clog up the socket with lots of small packets of data for no benefit (the user won't notice that they are getting 10 updates/second instead of 2 updates/second).
I am working upon an application based on client and server making use of sockets,in this i am sending data from client to receiver and have made sleep call for 10 sec in server side.Now,when i am sending data from client 1000000 times the server receives it very slowly and the client is printing the values but it is also taking some time in doing so.So, i need to clear following points:
-In both client and server when the values are being displayed there is no loss of data on either side.Does this means that the recv call which is on server side is blocking?
-Secondly,is there any good documentation which could help me to understand better the blocking and non blocking concept of the send and recv calls which are used in sockets programming.
When a server accepts a client over a tcp/ip connection, a new socket is created.
Is it safe to use the LocalEndPoint port (from the client perspective) as an id?
Example (from the server perspective):
int clientId = ((IPEndPoint)client.RemoteEndPoint).Port;
On my local machine, the port seems to be unique, but with multiple clients on different machines, it may not always be the case.
My second question:
Let's say the port can't be used like a unique id, how the server (and hence the protocol stack) can differentiate between two client socket (from the server perspective).
TY.
The uniqueness of a socket is identified by 4 values: (local IP, local port,remote IP, remote port) and that's how the protocol stacks identify a connection.
Given this, you can have several connections from the same port number to same port number but e.g. to a different remote address. Typically you have to specifically request
permissions to use the same local port for more than 1 outbound connection.
Your example int clientId = ((IPEndPoint)client.RemoteEndPoint).Port; doesn't use the local port, but the port on the remote end. This is certainly not unique, as different clients might happen to chose the same port. Your server port is probably fixed, and will always be the same for all connections. Thus if you want something unique on the server side, you have to use the 4 values mentioned above.
However if you only need a unique identifier within your own client application among connections you've set up yourself, the local port will do.
Don't use the remote end point - create a GUID - for each (accepted)connection.
Pass the GUID back to the client socket - get the client to save it (much better than a HTTP session) and add the GUID to any subsequent HTTP headers directed at you :)
then!! the perfect need for a HastTable<> !!! only a couple of situations I know of!
Why not just use "client" as the unique identifier. A unique identifier need not be of a value type.
The short answer to the first question is probably no. The client OS will usually pick a port from a range. Even if that range is 40-50 thousand large, if your server is busy enough, sooner or later you may have the same port coming in from different clients. If it isn't a busy server you may get lucky.
Sockets are differentiated from each other based on pairs of address/port/protocol. The combined set of these values from the client and server will be unique.
Why can't you just use the client address and port as a temporary id?
I am new to Async Socket Connection. Can you please explain. How does this technology work.
There's an existing application (server) which requires socket connections to transmit data back and forward. I already create my application (.NET) but the Server application doesn't seem to understand the XML data that I am sending. My documentation is giving me two ports one to Send and another one to Receive.
I need to be sure that I understand how this works.
I got the IP addresses and also the two Ports to be used.
A socket is the most "raw" way you can use to send byte-level TCP and UDP packets across a network.
For example, your browser uses a socket TCP connection to connect to the StackOverflow web server on port 80. Your browser and the server exchange commands and data according to an agreed-on structure/protocol (in this case, HTTP). An asynchronous socket is no different than a synchronous socket except that is does not block the thread that's using it.
This is really not the most ideal way to work (check and see if your server/vendor application supports SOAP/Web Services, etc), but if this is really the only way, there could be a number of reasons why it's failing. To name a few...
Not actually getting connected or sending data. Run a test using WinsockTool (http://www.isatools.org/tools/winsocktool.msi) and simulate your client first to make sure the server is working as expected.
Encoding incorrect - You're sending raw bytes across the network... Make sure you're using the correct encoding to convert your XML into bytes (ASCII, UTF8, etc).
Buffer Length - Your sending buffer (the amount of data you can transmit in one shot) may be too small or the server may expect a content of a certain length, and your XML could be getting truncated.
let's break a misconception... sockets are FULL-DUPLEX: you connect to a server using one port, then you can send AND receive data through the same socket, no need for 2 port numbers. (actually, there is a port assigned for receiving data, but it is: 1. assigned automatically when creating the socket (unless told so) and 2. of no use in the function calls to receive data)
so you tell us that your documentation give you 2 port numbers... i assume that the "server" is an already existing in-house application, and you are trying to talk to it. if the doc lists 2 ports, then you will need 2 sockets: one for sending and another one for receiving. now i would suggest you first use a synchronous socket before trying the async way: a synchronous socket is less error-prone for a first test.
(by the way, let's break another misconception: if well coded, once a server listen on a port, it can receive any number of connection through the same port number, no need to open 2 listening ports to accept 2 connections... sorry for the re-alignment, but i've seen those 2 errors committed enough time, it gives me a urge to kill)