I have this binding socket:
Socket mainSocket = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.IP);
mainSocket.Bind(new IPEndPoint(IPAddress.Parse("127.0.0.1"), 0));
And I need to know when an extern client is connected and disconnected from my servicies( ftp, database server, app server, etc).
thank for advance.
What I have tried:
I tried with these methods but, did not work for me.
mainSocket.BeginConnect(new IPEndPoint(IPAddress.Parse("127.0.0.1"), 0), new AsyncCallback(ClientConnected), null);
mainSocket.BeginDisconnect(true, new AsyncCallback(ClientDisconnected), null);
private void ClientDisconnected(IAsyncResult ar)
{
// here get some client info like Ip
}
private void ClientConnected(IAsyncResult ar)
{
// here get some client info like Ip
}
I need some help please. Thanks.
BeginConnect() and BeginDisconnect() are asynchronous operations. They are not events you can subscribe to.
BeginConnect() is for a client socket to asynchronously open a new connection to a server. BeginDisconnect() asynchronously closes an open socket.
To detect clients connecting to your server, you need to use Accept(), BeginAccept()/EndAccept(), or AcceptAsync() to accept inbound connections coming into your server socket. You will be given a new Socket for each accepted client to use for communicating with them.
There is no event for a client disconnecting from a server. If a client disconnects, pending/subsequent send/receive operations involving that client will fail. You need to handle those failures when they occur. For instance, if a client disconnects gracefully, a read operation from the client will end as successful with 0 bytes reported. But if the client disconnects abnormally, a read operation will end as failed with an error code reported.
Related
We have a situation where client writes faster than the server can read, say every 1 second or less a client writes to a server making the tcp socket buffer full and therefore disconnects.
How to handle this sort of situation?
Is there a way to check tcp socket buffer from client side before writing and waits until buffer is freed and can send again?
Here is a sample pseudo code to easily reproduce the issue
Server
socket = create server Socket at port 7777;
socket->Accept(); //wait for just 1 connection
while(true)
{
// just do nothing and let the client fill the buffe
}
Client
socket = connect to localhost 7777
while(true)
{
socket->write("hello from test");
}
this will loop until write buffer is full, and it will hang up, and will disconnects with win socket error 10057.
I want to setup a datastreaming server in Processing, so the Client sends a String to the Server and the Server answeres it. For example Client - Server "Cupcake" then Server - Client "Cupcakce sounds funny" so the Server answeres the string. I tried this with the UDP library and opened the port on the server. But when the server had to answer the Clinet it did'nt work, because I can't open the client's ports. Any solutions?
Sounds like you need two-way communication.
Using UDP you would need two sketches that are both UDP servers and clients.
e.g.
sketch #1 listens on port 12000
sketch #1 sends data on port 12001
sketch #2 listens on port 12001
sketch #2 sends data on port 12000
You can also use TCP sockets.
As the Server you can use Examples > Libraries > Network > ChatServer
I'm surprised there's no ChatClient example, but you can get away with something like this:
import javax.swing.*;
import processing.net.*;
int port = 10002;
Client myClient;
void setup()
{
size(400, 400);
textFont(createFont("SanSerif", 16));
myClient = new Client(this, "localhost", port); // Starts a client on port 10002
background(0);
}
void draw()
{
background(0);
text("client - press ENTER to type\nconnected:"+myClient.active(), 15, 45);
}
void keyReleased() {
if (keyCode == ENTER) {
String message = JOptionPane.showInputDialog(null, "message: ", "TCP Client messaging", JOptionPane.QUESTION_MESSAGE);
println(message);
if (myClient.active() && message != null) {
myClient.write(message);
}
}
}
Note: The server must be running before the client so the client can connect.
Be sure to checkout the difference between UDP and TCP protocols to work out which one makes most sense to use in your case (especially if you pan to use more clients).
Another option worth looking into is WebSockets. This would allow you to have a WebSocket server in Processing and the client could either be another Processing sketch or simply any browser with WebSocket support(e.g. most modern)
I am using socket.io to establish a socket connection. The server i am trying to establish connection with is first behind a Amazon ELB then a HAProxy load balancer. I am using this code:
socket = io.connect(url, {
'path': exports.baseURL + "socket.io",
'resource': resource,
'max reconnection attempts': 3,
'sync disconnect on unload' : false,
'transports' : ['websocket']
});
Almost half of the times this call is returning the valid socket object but other times it's returning disconnected socket object of this type:
Socket
_callbacks:Object
acks:Object
connected:false
disconnected:true
ids:0
io:Manager
json:Socket
nsp:"/"
receiveBuffer:Array[0]
sendBuffer:Array[0]
subs:Array[3]
Main this here to notice is here connected:false and disconnected:true means the connection is not getting established. Can someone please help here?
I am developing an application in which i am using socket for the communication between server application and client application(web and desktop both). My server application continuously listening the request of the client application and accept the request whenever comes.
Server code :
TcpListener listener = new TcpListener(IPAddress.Parse(ipAddStr), portNum);
listener.Start();
while (listen)
{
TcpClient handler = listener.AcceptTcpClient();
// doing some stuff
// for every client handler i am creating a new thread and start listening for the next request
}
and for web client i am using WebSocket, as for establishing the connection with WebSocket client we have to follow some handshaking process. and for that I am using the following code (which is working fine) :
static private string guid = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
private static string AcceptKey(ref string key)
{
string longKey = key + guid;
SHA1 sha1 = SHA1CryptoServiceProvider.Create();
byte[] hashBytes = sha1.ComputeHash(System.Text.Encoding.ASCII.GetBytes(longKey));
return Convert.ToBase64String(hashBytes);
}
generating and sending response for handshaking with websocket client:
// generate accept key fromm client header request
var key = headerRequest.Replace("ey:", "`")
.Split('`')[1]
.Replace("\r", "").Split('\n')[0]
.Trim();
var responseKey = AcceptKey(ref key);
//create the response for the webclient
var newLine = "\r\n";
var response = "HTTP/1.1 101 Switching Protocols" + newLine
+ "Upgrade: websocket" + newLine
+ "Connection: Upgrade" + newLine
+ "Sec-WebSocket-Accept: " + responseKey + newLine + newLine;
//send respose to the webclient
Byte[] sendBytes = Encoding.ASCII.GetBytes(response);
networkStream.Write(sendBytes, 0, sendBytes.Length);
networkStream.Flush();
I have also TcpClient socket used for desktop application, so the problem is how to identify that the request is from WebSocket or from TcpClient ?
The easiest way would be to have a websocket listener and the vanilla TCP listener listen to different port numbers. You should do that anyway, because it is customary for websocket applications to run on the standard http port 80 (or standard https port 443 when you use websockets with TLS), while a custom protocol based on TCP should run on one of the ports from the "registered" range between 1024 to 49151. You are well-advised to follow this, because a well-secured client environment which allows web access but not much else might not allow the user to connect to other ports than 80 and 443, while any non-http traffic on these ports might trigger an intrusion detection system.
When you still want to handle both protocols on the same port for some reason, it will be a bit difficult. Websocket is a protocol based on TCP which looks like a vanilla HTTP GET request at first, until you receive the headers Connection: Upgrade and Upgrade: websocket.
That means connection requests for either protocol need to be accepted by the same listener at first. Only after the client sent enough data to identify its connection attempt as either your custom protocol or websocket (or something completely different which accidentally connected to your port - you will encounter that a lot when you deploy your application facing the internet) and then delegate the communication with the client to the appropriate handler class.
A TcpClient is a Socket wrapper.
WebSocket is a protocol that can run over a TcpClient. WebSocket protocol defines the handshake and how to frame data.
The best way of differentiate simple TCP connections and WebSocket connections is to have them listening in different ports, since you are going to use different protocols. It would be bad if you have them in the same port, it will become a mess.
client:
socket(), connect() and then
for (1 to 1024) {
write(1024 bytes)
}
exit(0);
server:
socket(), bind(), listen()
while (1) {
accept()
while((n = read()) {
if (n == -1) abort(); /* never happended */
total_read += n
}
close()
}
now, client runs on Mac under NAT and server runs on my VPS (abroad)
generally, it works fine (client send all data and exit & server recv all data)
however, when client is running but suddenly the network is broken for couple minutes(and regain), the client won't exit after a long long time... I kill it with control + C and run it again, the server seems not read the data any more (client is still running)
here is what netstat shows:
client:
tcp4 0 130312 192.168.1.254.58573 A.B.C.D.8888 ESTABLISHED
server:
tcp 0 0 A.B.C.D:8888 a.b.c.d:54566 ESTABLISHED 10970/a.out
tcp 102136 0 A.B.C.D:8888 a.b.c.d:60916 ESTABLISHED -
A.B.C.D is my VPS address
a.b.c.d is my public client address
my quesiton is:
1, why ?
2, server will works fine after restarting, how to write code to get rid of it without restarting ?
In TCP, there's no way to tell that a connection has failed unless you try to send something on the connection. TCP doesn't perform active monitoring of the connection (actually, there are optional "keepalive" packets, but these are not normally sent until the connection has been idle for a couple of hours). When you send something, you'll eventually get an error if there's a timeout waiting for the other machine to return an acknowledgement. But if you're just reading data without sending, you can't tell that the connection has failed -- it just looks like the sender doesn't have anything to send.
You can resolve this by designing your application so that the client is required to send something every N seconds. Then set a timer in the server that detects that you haven't received anything for more than N seconds (you should add a little extra time to allow for transient delays).
When the network is broken what happens is that you clients keep sending data and at some point the socket send buffer gets full (I understand from what you show that you are sending 1024 Bytes, 1024 times, 1MB in total). The default for send buffer could be 16KB (surely less than 1MB). Then when the client tries to write, it gets blocked forever.
BTW, now I'm answering your question I don't know whether eventually after a number of TCP timeouts, TCP gives up and closes the socket making the socket interface return with error. I think that's not happening ... :) - So, connect fails if there is a problem in the network but write and read do not fail.
In the server side, the server gets blocked in read because it never receives the EOF.
Solution:
In the client side use non-blocking sockets, if the network is broken, at some point write will return with error EWOULDBLOCK. Then you will realize the send buffer is full for some reason. At that point, you could clouse the connection and try to connect again. If the network is broken, you will receive an error.
In the server side also use non-blocking sockets and select() function with a timeout. After a few timeouts you may decide there is a problem with the new connection and close it.